1. 開発工程とテスト
この連載のタイトルは「テンプレートから学ぶ……テスト仕様書」です。「テンプレート」と「テスト仕様書」がキーワードです。これらに加え、次回以降新たに「（IEEE）テスト文書」という言葉が出てきます。たくさんの言葉が出てきてややこしくなる前に、今回は開発工程とテストの関係について復習しておきましょう。
今回、テンプレートの改訂はありません（従ってダウンロード・ファイルもありません）。前回までのテンプレートを参照してください。
1.1. 開発工程
図1に簡略版の「開発工程」を描きました。ここでは
- 要件定義
- 設計
- 実現
- 単体テスト
- 統合テスト
- 受入テスト
が描かれています。
1.1.A. 要件定義
要件定義では何を作るかを書きます。要件定義の成果物は要件仕様です。それは図2のような目次からなります（参考文献4）。ここで、「機能」「性能」「使用可能性」「セキュリティ」「保守性」などの言葉が使われていますね。これは品質を構成する要素です。結局、要件定義は品質を定義しているのです。
1.1.B. 設計
要件定義が終わると設計に入ります。設計は対象システムをどう作るのかを検討する作業です。
設計では下記のような活動を含みます。
- 分割統治：大きくて複雑なものはすぐにはできません。小さく簡単なものに分割して開発しやすくします。
- 試行錯誤：初めてのシステムは何をどう作ったら良いのかわかりません。色々試してみます。
- 調整：要件仕様は実は相反することがあります。たくさんの機能を盛り込んだので性能要件を満たさない、などです。要件に優先順位を付けたり、実現可能な落としどころを探ったりします。
1.1.C. 実現
以前は「実現=プログラミング」でしたが、最近は再利用したりパッケージのカスタマイズをしたり、市販のソフトウェアを使ったり、要件を満たすように実現する方法も様変わりしています。どのように実現しようとも、大きなシステムを組み上げていくことになるので、プログラミングだけでなく各種設定など手を加える部分も多いのです。
テンプレート1に「1.2. テスト内容」を再掲します。これはテスト対象でしたね。つまり「手を加えた部分なので、テストしましょう」ということです。
1.1.D. 単体テスト
「手を加えた部分なのでテストする」対象が「小さな要素」であるテストを単体テストと言います。「単体テストとは何か」は、今まさに連載中なので、詳しくは第2～4回を見ることにしましょう。
1.1.E. 統合テスト
設計では「大きくて複雑なものはすぐにはできないので、小さく簡単なものに分割」しました。統合テストでは逆に「小さな要素」を組み上げてテストすることになります。「統合（インテグレーション、integration）」とは、そういう意味を込めて使っている言葉です。
1.1.F. 受入テスト
図3「仕様と成果物」は当連載 第1回目で使った「図1 ソフトウェア開発プロジェクトと品質・生産性・納期」を再掲したものです。
発注者が検収するとき、仕様に照らして成果物を受け入れて良いかどうか判断します。受け入れがたい成果物の時、その成果物の品質は悪いと言いますね。品質とは成果物が仕様を満たしているかどうかの尺度なのです。
ですから、仕様には「機能」「性能」「使用可能性」「セキュリティ」「保守性」などの品質要件を書いたのでした。
この検収をするに足るテストを受入テストと言います。成果物を要件に照らして受け入れてよいかどうかを判断するためのテストです。
