「何を確認したいか」から「ソフトウェアテストドキュメントに何が必要か」を考える
ソフトウェアテストのドキュメントはテストの実施後に完成する実施報告書とテスト実施前に実施計画やどういうテストケースを実施するかを記載するドキュメントに大別できます。ここでのドキュメントはきっちりとした書式に埋めていくものもホワイトボードに書いた内容やメモ書き程度のものも両方含みます。テストツールへのインプットやテストコード自体はテスト実施前のドキュメントに該当し、実行結果が実施報告書に含まれるでしょう。
テストの実施計画やどういうテストを実施すべきかといった準備はプログラムが動作する前に開始することができます。規模の大きなソフトウェア開発であれば、個別のドキュメントとして残すこともありますが、仕様書に付記されたり設計書の一部に含まれていたりすることもあります。たとえば、仕様を確定する段階で、個々の仕様に対してどういうテストケースによってその仕様を満たせたと言えるかといった対応付けをすることもあります。そうした対応付けをトレーサビリティマトリクスのような形式でドキュメントに残すこともあります。
これらのドキュメントを対象にテストが妥当かどうかを明らかにすることを目的として自己チェック、他者による確認、関係者の間で合意ができます。テストの計画やテストケースが妥当か、省略できるテストケースはないかといった点でチェックします。「このテストケースで何を確認しようとしているか」という目的を記載したり「なぜこのテストケースが必要か」といった分析の経緯や根拠を記載すれば、実施しようとするテストが妥当であるかを判断しやすくなります。
しかし、多くのドキュメントでは意図というよりは分類が書いてあり、分類に対応するテストケースが羅列してあります。大分類、中分類、小分類といった分類があり、大分類には仕様書や設計書の機能一覧から取り出した個々の機能が、中分類にはそれぞれのサブ機能やサブコンポーネント、取り得る状態、実行条件が、入出力のようなパラメータが小分類として記載されているドキュメントをよく見ます。非機能要求を確認するテストは別立てで表形式になっていたり各機能に対応づけられ中分類に入れられていることもあります。
これらの分類だけでは「このテストケースで何を確認しようとしているか」「なぜこのテストケースが必要か」という疑問を解決できない場合があります。かといって、「根拠や分析結果をすべて記録に残せ」というのは書くコスト、読むコストが大きくなる上、たくさん書いてあるからといって必ずしも意図が読み取れるようになるものではありません。
そうしたテストの意図、仕様やユーザの期待とテストケースの間にどのようなつながりがあるかを記したドキュメントを使ってどういう情報を共有し、どういう方法でテストが妥当かを確認するかという点を明確にすることができます。たとえば、テストケースの十分性を確認したければ、テストスイート（テストケースの分類）、テスト対象、テストスイートの目的が書かれていると確認しやすくなるはずです。「こういう目的であれば、こういうテストケースも必要ではないか？」「このテスト対象が抜けているのではないか？」といった議論がしやすくなります。
特に短納期、小規模開発でテストに関するドキュメントが実施報告書のみで、上述のようなテストの意図を記したドキュメントがない場合、担当者の頭の中だけで完結していることが多いようです。書き出してみるとムダやモレが見つかることも少なくありません。こうしたドキュメントに残すべき必要最小限の情報を洗い出し整理することは結果として効率化につながることも少なくありません。
言い換えると「どういうレビューをするか」を決めると「どういう情報が必要か」ということが明らかになります。「テストをわかりやすく共有する」というテーマで2014/10/31(金)にソフトウェアテストシンポジウム東海が開催されます。基調講演では私から上述の内容と一般的なドキュメントレビューを紹介します。テストの意図を記すドキュメントをどういう問題検出シナリオでレビューすべきか、そのためには何を書いておくべきかを一緒に考えましょう。