「テストを実施すると必ずバグを見つけることができますか？」と聞かれると、筆者の回答は“⁠No⁠”です。テストによるバグを検出は、実施した結果が期待値と異なる事象のときに発見されます。テストにおいての期待値とは、テスト対象が動作した「正しい結果」です。

テストケースを見ると期待値の設計はされていますが、ほとんどの場合は期待値以外の結果が記述されることはありません。テストの実施においてテストケースに記述されている期待値以外の結果は、テスト担当者の判断に委ねられます。この期待値がバグを発見する重要な鍵を握っています。

あるプロジェクトの情景

ある製品のテストを担当したTさんとテストマネージャのM氏の会話を聞いてみましょう。

M氏：

「先週のテストの実施結果を報告してくれ。」

Tさん：

「テストの計画通りにテストケースを実施しましたが、不具合の検出率が低いようです。」

M氏：

「それは、テスト対象の品質が良かったからか？」

Tさん：

「実は、テスト実施後にいくつかの不具合が他のチームで検出されて問題になっています。どうやら、検出された不具合は今回のテストで発見すべきだと指摘を受けています。」

M氏：

「検出できなかった原因の判明はできているのかね。」

Tさん：

「問題の不具合は、テスト範囲に入っていたのですが、テストケースの期待値に表現されていない部分の問題のようです。⁠」⁠

M氏：

「どういうことなんだ！」

Tさん：

「それは……」

Tさんに代わり筆者が説明をします。今回の問題は、テストケースの期待値に問題があったようです。テストの結果は実行条件などによって動的に変化するケースがあります。すごく簡単な例として、現在時刻を表示する機能などは常に結果が変化します。2人の会話から察すると、もっと複雑な事象が発生したのでしょう。

テスト技術者は常識人

ずばり、「⁠テストで不具合を発見する」には、期待値を知っておかなければいけません。テストの対象物の仕様はもちろんのこと、性能や使い勝手など仕様に現れない部分も重要です。

実際のテストでは、仕様書を見てテストケースを設計します。期待値も仕様書に書かれている範囲で設計します。つまり、仕様書に書かれない「見えない仕様」は、テストケースから漏れてしまう可能性があるのです。このように「見えない仕様」部分は、テストする担当者に依存し、担当する人によって異なるテスト結果をもたらしてしまいます。テストの担当者は、テストの対象物について十分な知識と理解がないと、バグを見逃すことになります。

筆者は、このようなテストを実施しているのにバグを見逃してしまう現象を“⁠（目では）見ているのに（頭では）見えていない状態⁠”と呼んでいます。

それでは「見えない仕様」をどのように考えれば良いのでしょうか。難しく考える必要はありません。ほとんどの場合は、テストの対象をじっくり調べ、常識的に判断すれば良いのです。テストの対象をよく知る、常識的な判断ができる人、それがテスト技術者です。

ブレストは、知識と発想、そして人を磨く

テスト技術者であり続けるためには、常に知識を得る努力が必要です。知識とは、状況や環境が変わると使えなくなります。筆者は20年以上前に自動車の免許を取得しましたが、当時の道路交通法は何度もの法改正を経て、新しく改正されています。過去に取得した免許だからといって、その当時の法律のままでは通用しません。常に新しい法律に従わなければ、交通違反を犯してしまいます。このように、一旦得た知識も変化が求められます。

絶え間なく知識を得る努力は大変ですね。そこで、有効な方法を提案します。それは、「⁠ブレインストーミング」です。一人の知識には限界がありますが、さまざまな立場の人が集まってブレストすること、ブレストから新たな知識と発想を得ることが近道です。さあ、一人で考えていないで、みんなでブレストしましょう。

次回は…？

次回は、テストの「禁断領域」に迫ります。それは「テストの性善説⁠」⁠─正しいテストを実施している自信はありますか？ テスト担当者が判定したテスト結果のOK／NGは大丈夫ですか？ あなたのテストを分析してみます。