レポート

テスティングにまつわる過去,現在,未来をDorothy Graham氏が語る─ソフトウェアテストシンポジウム 2013基調講演

この記事を読むのに必要な時間:およそ 3.5 分

テストの価値を計る「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氏⁠⁠。

講演後の質疑応答で「DDPでテスターを評価してはいけません。能力を見誤ることになります」と釘をさしていました

講演後の質疑応答で「DDPでテスターを評価してはいけません。能力を見誤ることになります」と釘をさしていました

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

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さんは「探索型テストを自動化するのではなく⁠探索的な性質を持った自動化手法⁠が出てくるという意味だった」と答えています。


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

著者プロフィール

小坂浩史

gihyo.jp編集部 所属。最近では電子書籍の制作にも関わる。

バックナンバー

2013年

バックナンバー一覧