テンプレートから学ぶ
受注する開発者のためのテスト仕様書

1. はじめに

　ソフトウェア開発プロジェクトにおいてテストは極めてストレスに満ちています。「テストとは作った成果物に誤りがあるかどうかを見つける作業だ」という本質的に不愉快な活動であることに加えて、プロジェクトの終わりにさしかかって時間も逼迫しているのに仕様変更を受けて再テストなどという、体力的にも精神的にもきつい作業であるからです。

　本稿では、さまざまなストレスを受ける立場の開発者が少しでも楽に「きちんとテストしました」と言うために、テスト仕様書のテンプレートを紹介します。このテンプレートは発注者に報告するための文書だけでなく、さまざまなテスト技法の紹介も含まれていて、いつどういうテストをすればよいのかという手引きにもなっています。

　さて、はじめに、ソフトウェア開発プロジェクトと品質・生産性・納期の関係を見てみましょう（図1）。

図1　ソフトウェア開発プロジェクトと品質・生産性・納期

　お客様（発注者）はプロジェクトを起案する際、何を作るかを「要件仕様」という形にとりまとめた上で時間・予算を手当てします。開発者（受注者）は受注すると、仕様を基に開発し、成果物を納品します。お客様は成果物を仕様に照らして検収し、受け入れると代金を払います。

　さらに図1で、品質・生産性・納期を次のように定義します。

• 「品質」とは、成果物が仕様に照らして合致しているかどうかの性質
• 「生産性」とは、投資した代金（コスト）に対する成果物の付加価値
• 「納期」とは、受注してから成果物を納めるまでの期間

1.1. 発注者の立場

　この開発プロジェクトを発注者の立場で見てみましょう。

　「検収」とは、発注者が「成果物を仕様に照らして合致しているかどうか」を判断することなのですが、それは品質を見ていることになります（先ほど、定義しましたね）。では、品質を見るにはどうすれば良いのでしょう。一つの方法としてテストがあります。

　大きなプロジェクトだと、一口に発注者と言っても、組織の中のたくさんの人が関わる訳ですから、テストするにしても「目標、方法、実際の手順、結果、品質が悪いことがわかった時の対処方法、など」実に様々なことが文書になっていなければなりません。

　また、発注者としては、開発の最後にまとめて成果物を渡されると、仕様を満たしていなかった場合に対処する時間がなく、困ってしまいます。そのため、局面ごとに「きちんとテストしました」と報告を受けたいところです。

1.2. 受注者の立場

　受注者は上記「発注者の立場」で述べたテストに必要なことを行うことはもちろんですが、他の考慮点もあります。

• プロジェクト開始時点や初期では、発注者からの仕様書がないことがあります
• 発注者からの仕様は往々にしてきちんと書かれていません（曖昧であったり、不完全だったりします）
• プロジェクトの後半にさしかかってくると、ようやく固まってきた仕様が変更されることがあります