PR

 開発と同じく、ソフトウエアテストでもドキュメントを作成する。作成をサボったり、ドキュメントが的外れだったりすると、後続プロセスの担当者が困る。抜け漏れや誤りだらけだと、インプット資料として使い物にならないからだ。今回はテストで作成するドキュメントの種類と内容のポイントを解説しよう。あるSIベンダーの若手社員「ワカテくん」はテストエンジニアになるための研修の真っ最中。最初の山場であるテスト計画を終えたようだ。

ワカテ:テスト計画の作業がようやく終わりました。決めることが多くて大変でしたよ。

センパイ:お疲れ様。じゃあ、決めたことをドキュメントに残さないとね。

ワカテ:どんなドキュメントを書けばいいんでしょう。文章は苦手だし面倒くさいな。検討中の議事録をそのまま残すのでは駄目でしょうか。

センパイ:駄目だよ。この後のテスト設計を担当する人が困るんだ。テスト計画で決めたことがきちんと伝わらないと、テスト設計の作業はできないからね。考えてごらん。実はワカテくんしか知らないこともあるんじゃないのかな。

 テストには、テスト計画、テスト設計、テスト実行、テスト管理といった4つのプロセスがある。1つひとつのプロセスは、インプットとなるドキュメントを基に作業を実施し、その結果をアウトプットとなるドキュメントに落とし込む。例えばテスト計画プロセスでは、プロジェクトの関連文書や要件定義書をインプットにテスト計画の作業を実施し、作業のアウトプットとして「テスト計画書」を作成する。

 こうしたドキュメントは、先行するプロセスと後続のプロセスをつなぐ役割を果たす。テスト計画書は後続するテスト設計プロセスのインプットになる。テスト実行では、先行するテスト設計プロセスで作成した「テストケース」がインプットとなる。このように、先行するプロセスのアウトプットが後続のプロセスのインプットとなる関係にある。

ドキュメントは後続プロセスへのバトン
ドキュメントは後続プロセスへのバトン
[画像のクリックで拡大表示]

 ドキュメント作成を怠ると、先行したプロセスで決めた事項が後続のプロセスに伝わらなくなる。例えば、テスト計画で実施すべきテストをきちんと計画していても、ドキュメントが不十分だとテスト設計の段階で抜け漏れが生じる。短期的にはドキュメント作成の手間がかかっても、テストプロセスの手戻りを削減する効果は大きい。

 なお、プロセスのアウトプットとして作成するドキュメントの形式やボリュームはプロジェクトによって異なる。様々な会社の関係者が何百人も関わる巨大なプロジェクトであれば、厳密な記載をしたドキュメントを作成する。こうしたプロジェクトで怖いのは、関係者間で誤解が生じたままプロセスが進んでしまうことだからだ。

 関係者が既知のメンバー数人というプロジェクトであれば、メモのような簡易なドキュメントでもいい。小規模なチームならば、こまめにコミュニケーションを取りながらプロセスを進めることができる。コミュニケーション結果を簡易なドキュメントに残せば、最新の状況をチームメンバーで共有していける。

 今回はテスト計画、テスト設計、テスト実行の3つのプロセスについて、どのようなドキュメントを作成する必要があるかを解説していこう。