テスト文書の「テスト項目仕様」および「テスト手続き仕様」

開発者のためのテスト仕様書テンプレート（7）

4.「テスト手続き仕様」

　テンプレート3にテスト手続き仕様の各項目を掲げました。

テンプレート3: 「テスト手続き仕様」

　各項目は以下の通りです。

• 「ID（識別子）」は表の要素（エントリー）を識別するために、用意します。
• 「TestProcedureID（テスト手続仕様番号）」はテスト手続仕様（この表）を他の表から参照する時に使います。
• 「TestDesignID（テスト設計仕様番号）」はテスト設計仕様を参照しています。
• 「TestCaseID（テスト・ケース仕様番号）」はテスト・ケース仕様を参照しています。
• 「Purpose（目的）」はこのテスト手続の目的を記述します。
• 「SpecialReq（特別な要件）」は特別な要件があれば記述します。
• 「ProcedureStep（手続き）」は以下の手続を記述します。
テンプレート4: 「手続き」

• 「Responsibilities（責任）」は責任者の氏名を書きます。
• 「Date」は4項目あって、プロジェクト管理用に使います。
  • DateInPlanned（予定開始日）
  • DateOutPlanned（予定完了日）
  • DateInActual（実開始日）
  • DateOutActual（実完了日）

4.1. テスト手続き

　私はIBMに入社したのは1978年4月ですから、この3月でもう32年もIT業界に居ることになります。直接・間接にソフトウェア開発保守のプロジェクトに関わってその数も少なくないのですが、仕様書がきちんと揃っているプロジェクトに出会ったことはありません（溜め息。

　ユーザが要件定義で書いていないことを開発途中で要求するのは日常でした。その追加要件も仕様書になっていれば良い方で、現行の帳票イメージ、現行の画面のハードコピー、現行の操作マニアル、監督官庁からの冊子、走り書きのメモ、板書、口頭、沢山のメールに散在する断片、不確かな情報しかないURL、など、まことに雑多です。

　さて、ここで単体テストのテスト手続きです。テンプレート4に書かれている「手続き」は、結構詳細で、該当プログラムの動きがわかっていないとなかなか書けるものではありません。「仕様書がないのに！」です さあ、どうしましょう。

　今が書くチャンスです。分からないことはユーザに聞いて、この「テスト手続き仕様」の「テスト手続き」を書きましょう。この「テスト手続き仕様」が参照している設計書の該当部分にこのプログラムの動きが書かれていないなら、今、書きましょう。こうして、本来書くべきだったが書いていない仕様を今、書いてください。

　テスト仕様に対する向き合い方が、なんとなく伝わったでしょうか。

5. まとめ

　IEEEのテスト文書のうち、テスト項目仕様とテスト手続き仕様を学びました。

参考文献

1. 『SEのためのソフトウェア・テストの基本』 山村吉信 著、翔泳社、2003年12月
2. IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology
3. IEEE Std 829-1998 IEEE Standard for Software Test Documentation
4. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications
5. IEEE Std 1016-1998 IEEE Recommended Practice for Software Design Descriptions