テストケースの文書類には、期待される正しい結果を詳細に記述したものを含めなければならない。もし、これらが省略されると、テスト実行者がそのソフトウェアが成功したかまたは失敗したかを判断する方法がない。さらに、テスト実行者には、潜在的に正しい結果を見たいという気持ちが働くので、正しくない結果を正しいと判断するかもしれない。もっと悪いことは、テスト実行者が、正しい結果を正しくないと判断し、その結果、設計者やコーダーが、あわてて正しいコードを「いじって」しまうことである。
中間および最終テストケースの予期される結果を文書化することを規定する、組織としてのテスト計画のための企画を作成せよ。そして、品質保証部門は、すべてのテスト計画が、この企画に従っているかどうかを確認すべきである。
（２０１の鉄則：原理１１６＜テスティングの原理＝テストケースには期待される結果を含めよ＞）
テストは、開発作業の犠牲になる傾向があります。開発部門での作業の遅れは、テスト作業を圧迫することになるし、適切な文書の省略などの設計プロセスの不備が、テスト作業を難しくします。そうはいっても、現実問題として、テストを省くことは出来ません。
設計の問題を含めて、テストのあり方を考えるのに、テストのどの作業に時間がかかっているか測ってみるとよいでしょう。現実のテスト作業を調べて、作業を定義すれば、時間などを記入するシートが作れます。
テストそのものに時間がかかっているとすれば、それはテストの量が多いからか、個々のテストに時間がかかっているからか。あるいは、エラーの状態での作業に時間がかかっているのか。原因が、テスト仕様そのものが用意されていないことにあるとすれば、全く論外な話です。
テスト仕様とは、ある機能が正しく実行されることを確認するために、どのようなテストを行うかが記述され、さらにどのような結果であればよいかが記述されていて、テスト実施者は、それに沿って作業を進めることになります。「こうなれば良い」という結果も書かれているので、テスト実施者の勝手な判断が入る余地はありません。もちろん、バグもあるでしょうから、テスト仕様書に沿っての作業は中断されるでしょうが、判断を間違う危険は小さくなります。
ところが、このテスト仕様書が、実際にはほとんど書かれていません。昔居たことのある、ある外資系のメーカーでは、膨大なテスト仕様書が存在していました。だが、そのようなテスト仕様書は、その後の国内の企業では目にしたことがないのです。そこではとても書けないという一言で退けられてしまいます。
テスト仕様書が書けない理由の一つに、もともと要求仕様書（主に機能仕様書）が書かれていないことが上げられます。要求を実現するために、具体的にどのようなことをさせようと考えられているのかが明確になっていれば、そこから、どのような状況で、どのように動作させてそのことを確認すればよいか、という観点からテスト仕様書が書けるのですが、その元ネタが無いために、テスト仕様も書かれないという結果になります。
もちろん、今日の状況では、両方を書くためのリソースの確保は困難なのかもしれません。でも、要求仕様に手を加えれば、テスト仕様が作れます。手書きの時代ではないのですから、そのことはそれほど難しいことではないでしょう。計画さえすれば実現することです。
一言で「テスト漏れ」といっても、実際は、テストケースとして設定されるのが漏れたということです。限界値テストとか網羅テストなどでテストケースが漏れるだけではなく、その機能が使われる「場面」の想定が漏れることがあります。これはテスターのスキルでもあるのですが、テスト仕様としての記述が省かれていることが、「場面」の想定を困難にしていることは確かです。このようなケースでは、市場に出てからバグが見つかることになるのですが、そのことは、同時に、設計者の間でもほとんど意識されなかったことを物語っています。
一般に、設計者の立場では「機能」を明らかにするところに重点が置かれます。でも、熟練したテスターは、その機能が使われる「場面」や「環境」に注目します。設計者も考えないわけではないのですが、どうしても一つの「場面」の中で機能を考えてしまう傾向があるため、違った場面でテストされると、途端にエラーとなってしまうのです。ここに、熟練したテスターの存在意義があるし、設計作業を終了する前に、テスト仕様書が書かれてくることの意義があるのです。テスト仕様書が完成していなくても、出来るだけ早い段階で、「場面」が記述されたテスト項目を設計者に見せることで、品質を折り込むことができます。同時に、テスト内容の検証も可能となるのです。
もう一つ、この原理が示しているのは、「品質保証部門（ＳＱＡ）」の責務として、このようなテスト仕様書の存在を確認し内容を検査することを求めていることです。一般に品質保証部門の活動は、テストを“実施する”ことに重点が置かれていることが多いと思われます。これは「保証」ということをどのように認識するかというところでの問題と思われますが、多くは、「バグがないことを保証します」という意味に解釈されているようです。もちろん、結果として、そのような判断も出来るでしょうが、その前に、適切にテストが実施される状況にあることを監査し保証する、という考えも必要なのです。もちろん、組織の役割として、品質保証部門がテストを実施するように定義づけられていること自体は問題ではありませんが、本来の「保証」の意味を正しく認識し、それに沿った活動が求められます。そうでないかぎり、“品質保証部門”は、いつまでも設計部門の下流部門に過ぎなくなります。まさに、これがＣＭＭのレベル２の取り組みの中で求められていることです。