今年も1月30、31日の2日間、「⁠ソフトウェアテストシンポジウム 2013 東京」（⁠JaSST '13 Tokyo／主催：NPO法人ASTER）が開催されました。今や全国7地区で開催されるようになった同シンポジウムですが、毎年この時期に東京で開催されるJaSST Tokyoはオリジナルイベントと呼べるもので、今年で通算11回目を数えます。今年も2日間で延べ1,800人が参加し、初日の登録受付の場では久しぶりに会ったエンジニア同士が旧交を暖めあう光景があちこちで見られました。

初日の基調講演には、毎年海外から業界の著名なテストエンジニアやコンサルタントが招かれます。今年はソフトウェア・テスティングコンサルタントのDorothy Graham（ドロシー・グラハム）さんが登壇しました。Dorothy Grahamさんは「Software Inspection」や「Foundations of Software Testing」などの著作（共著）で知られ、ヨーロッパ最大のテストカンファレンスEuroSTARの初代プログラム委員長やISEB Software Testing Boardの設立メンバーなどを歴任された方です。

「Challenges in Software Testing─ソフトウェアテストのチャレンジ」と題された講演は、Dorothyさんの40年におよぶソフトウェアテストとの関わりの中で、ソフトウェアテスト、テストエンジニアの地位がどのように変わってきたか（過去⁠）⁠、ソフトウェアテストについての実践的なアドバイス（現在⁠）⁠、そして自動化するテストをどのように位置づけるか（未来）という3部構成で進められました。

テストの歴史は“テストエンジニアが認められる”歴史

最初のパートは、ソフトウェアテストの歴史についてのおさらいです。Dorothyさんがベル研究所でキャリアをスタートさせた1970年代＝メインフレーム全盛のころから10年刻みで、世のコンピューティングの流れと対比させながらソフトウェアテストやテストエンジニアの状況について振り返りました。

まだソフトウェアテストが独立した仕事ではないころ、Dorothyさんは「思いがけず」テストに関わり、テストを取り巻く状況も眺めることになります。'80年代に入り、ソフトウェアテストの標準化が進みます。米国では初めてのソフトウェアテスト・カンファレンス（USPDI）が開催されました。初の商用テスティングツールも登場しています。とはいえまだテスト技術者は“⁠二流⁠”扱いで、開発者の方が高給でした。

世はパソコン時代、構造化プログラミング、GUI、クライアント／サーバ、オブジェクト指向などのトピックが登場します。「⁠これらは物事を簡単にしてくれるはずでした。でもそうはならなかった」（⁠Dorothy氏⁠）⁠。この頃あるCASEツールベンダと会ったDorothyさんがそのツールのテスト環境について尋ねると「このツールを使えばテストは必要ない」と言われ、「⁠それは違う」と議論になったそうです。「⁠このころテストは“⁠必要悪⁠”とはまだ見なされていませんでした」（⁠Dorothy氏⁠）⁠。

90年代に入り、インターネットの登場直前の1993年に、最初のEuroSTAR テストカンファレンスが開催されました。主催者側だったDorothyさんは、全然人が集まらないのではないかと気が気でなかったそうですが、蓋を開けてみればヨーロッパ中から300人が集まり大成功となりました。

そして2000年代～現在、テストを取り巻く状況は大きく変化しました。テストツールスイートやオープンソースのテストツールが登場し、TDDや探索型のテスト（Exploratory testing）が登場します。テスティングの標準資格としてISTQB（International Software Testing Qualifications Board）が生まれます。その前身の資格認定から携わってきたDorothyさんにとっても非常に誇らしいものとなったと振り返ります。

このISQQBの資格について「実用的ではない、レベルが低い」と批判する人がいますが、Dorothyさんは「それは不当な評価だ」と反論します。「⁠ISTQBがあることによってテスターという仕事が認知され、テストという工程を認識させることができたのです。テストが“⁠誰もができる⁠”から“⁠専門的スキルが必要⁠”な認識に変わった。これは大きなベネフィットです」（⁠Dorothy氏⁠）⁠。

まとめとして、この40年で何が変わったのかについて「テストエンジニアがきちんとしたキャリアとして認識されていなかったのが、ボス、雇用主、同僚から尊敬を集めるようになった」とあらためて繰り返しました。「⁠70年代には1冊しかなかったテストに関する本が今では数百冊になっています」（⁠Dorothy氏⁠）⁠。

逆に変わらないものとして「管理職の不理解（テストによって何ができ、何ができないのか理解できない⁠）⁠」⁠「⁠大学でのテスティング教育の不備」などを挙げました。さらに「過去に学ばない」のも問題だと言います。「⁠過去をふりかえるのは苦痛を伴うものですが、間違いから学ぶことが必要です。同じ過ちを繰り返してはいけません」（⁠Dorothy氏⁠）⁠。また、新しい技術が次々と出てくる点にも触れ、「⁠テストは技術と独立したものではありません。人はいつも間違いを起こすもの。継続して改善を求め行動することが重要です」と結びました。

テストの価値を計る「DDP」とは？

次のパートは現状への実践的なアドバイスとして、まずテスティングの価値についてのお話です。テストの目的はソフトウェアの欠陥を見つけることですが、ではテストをして欠陥が見つからなかったらテストをする価値がない、またはバグがないということでしょうか？ またたとえばテストで200個の欠陥を見つけたとして、それはテスト技術者が良い仕事をしたと言えるでしょうか？ リリース後に見つかった不具合が20個ならそこそこ良いと言えますが、これが1,000個だったら評価はまったく変わってしまいます。

こうしたテストの価値を数値化して見るための指標として、DorothyさんはDDP（Defect Detection Percentage：欠陥検出率）を取り上げました。

DDPは、（⁠テスト中に見つかった欠陥数⁠）⁠／（⁠テスト中～リリース後に見つかったすべての欠陥数）のパーセンテージで表されます。ですから、リリース直後でまだ利用者からの不具合報告のない状態だとDDP＝100％となりますが「それをやってはいけません」（⁠Dorothy氏⁠）⁠。あたりまえですね。通常はリリース後ある期間をとって計算します。当然、リリース後の時間が経つにつれ、DDPはどんどん下がっていきます。単純な指標で、完全な情報ではないから使う意味がないという意見もありますが、使い方によっては非常に有効とDorothyさんは語ります。このあといくつかの例を挙げ、DDPの使い方を説明していきました。

ある保険会社のファイナンスシステムでの例。最初の年は1ヵ月でDDP70％→10ヵ月で50％に。そこでテストの方法を改善したところ、2年目には1ヵ月目で92％に上がりました。「⁠どのような改善ができたか文書化できるのがいいところ」とDorothy氏。

一方ある科学計算ソフトでは、アプリケーションによってDDPが23％から87％と大きく幅のある結果が出ましたが、これはDDPの母数が大きく異なるデータを比較したためでした（1/4と160/200⁠）⁠。「⁠不具合検出数の少ない場合はDDPは有用ではない」（⁠Dorothy氏⁠）⁠。

DDPを使う場合の注意点は、一貫した見方でDDPを使うことです。そのためには、テストの方針をあらかじめ意志決定する必要があります。「⁠正確性は重要でありません。一貫性の方がより重要」（⁠Dorothy氏⁠）⁠。

テスト自動化の目的は「欠陥探し」ではない

2番目はテスト自動化にありがちな「知的な間違い」のお話です。

あるカンファレンスで会った管理職の人が「回帰テストを自動化して週末もずっと動かしているが、もう止めうと思う」と言いました。その理由を尋ねると「バグが見つからないから⁠」⁠。この話はなぜおかしいのでしょうか？ Dorothyさんは解説します。「⁠バグを見つけるのはテストです。自動化がテストを走らせるためのメカニズムに過ぎません。バグ探しはテストの目的には良いですが、自動化の目的としては適当ではありません⁠」⁠。

もちろん、自動化して最初に走らせるときはバグを見つけます。また、手動でカバーできないような膨大な組み合わせをテストする場合などは、自動化しなければ見つからないバグを発見できるでしょう。でもそれは「自動化の間接的な結果でしかない」（⁠Dorothy氏）のです。

同様の間違いとして、ツールがあればテスターは不要という意見もよく聞きます。しかしDorothyさんはこれを否定し、「⁠ツールは自分で“⁠もしかしたら⁠”とは考えない」といいます。「⁠ツールはつまらない反復作業からテスターを解放するもの。ツールがテスターを置き換えることはできない。テストを主導できないのです」（⁠Dorothy氏⁠）⁠。

また、「⁠自動化がテスト時間を短縮する」というのも間違いで、自動化されたテストの実行時間はたしかに短縮されるものの、メンテナンスやセットアップ、結果の分析には通常より多くの時間が取られるため、トータルではより時間を要す場合も出てきます。これを防ぐためにはスクリプトをモジュール化して保守を容易にするといった、より成熟させた形にする必要があります。

さらに「手動テストすべてを自動化すべき」という意見には、手動でやるより自動化した方が簡単になるものを選ぶべきと言います。「⁠年に1回1週間手動でテストすればいいものを自動化するのに2週間かかったら、メリットはありません」（⁠Dorothy氏⁠）⁠。自動化のメリットを最大化する判断が求められます。

そして危険な発想としてテストをROI（Return On Investment：投資対効果）で判断することを挙げました。ROIで見ると、テスターの労働時間で判断を行い、先に挙げたテスターにツールが取って代わるという結論になりがちです。自動化は成功させるための手段で、コスト削減ツールではないのです。

テスト技術者の未来は明るい

最後のテーマは、将来への課題です。まず技術的なトピックとして、クラウド、仮想化の普及、そしてソーシャル、モバイルへの対応が必要です。また開発手法としてAgileやCI（継続的インテグレーション⁠）⁠、DevOpsといったものが注目されてきました。これによって開発とリリースの境界線があいまいになりつつあります。

またテスト自体も、ユーザ自体がテストを行う視点で、テストのしやすさや「Testing as a Service」といったインフラの整備に注目が集まり、さらにテストがコモディティ化する気配もあります。「⁠テストを“⁠iTest⁠”からダウンロードする時代に？」（⁠Dorothy氏⁠）⁠。

そして自動化はこれからもさまざまなテスト分野に広がっていくと言います。CIにユニットテストが組み込まれたり、質の高い自動化が必要になってくるでしょう。探索型の自動化も進みそうです（※⁠）⁠。またテストのデータベース構築を自動化することなど、自動化の新たなメリットが模索されているとのこと。

これに伴いテスターの役割も変わっていくかもしれません。それは職を失うということでしょうか？ デベロッパがある程度のテストを行う環境が普及し、テスターもテスト用のスクリプトを書くなど、開発者に近い仕事をするようになりました。しかしDorothyさんは「テスターもコードを書くべきだとは、私は思いません」と言います。コードを書くのはテスト本来の価値ではないからです。「⁠コードを書く代わりに、不具合の原因究明などをデベロッパにアドバイスする存在に変化していく、そしてユーザやビジネスの問題に高度なレベルで対応できる存在になる」（⁠Dorothy氏⁠）⁠。そして最後に、「⁠テスティング、テスターにとって、未来は非常に面白いものになるでしょう」と結び、講演を終えました。

講演中ことあるごとに「テストエンジニア不要論」を明快に否定したDorothyさん。テストの黎明期から長きにわたってテスティングの価値の向上、そしてテスト技術者の地位向上にさまざまなアプローチで取り組んできたことが身に染みてわかる講演でした。