単体テスト仕様書＆報告書

詳細設計と単体テスト

   DUNGEONでは、"機能"単位に詳細設計書が作成されます。前回、詳細設計書について解説しましたが、そのテンプレートに示すように、"機能"には複数のモジュールが含まれます。

   例えば、「プロスペクト一覧」という機能は、「プロスペクト一覧」という画面と「プロスペクト検索」「プロスペクト印刷」「月別受注見込出力」という3つのビジネスロジックの合計4モジュールから構成されます。


共通モジュールの設計書は単独で

   DUNGEONでは、モジュール単位ではなく、機能単位で詳細設計書を作成します。これは、モジュール単位だと設計書が細分化され過ぎて機能要件が把握し難くなると考えているからです。そのため、機能に含まれるモジュールの仕様は、機能設計書の中に含んで記述されます。

   しかし、モジュールの中には複数の機能で共通に使われるモジュールが存在します。例えば、「在庫更新」というビジネスロジック（モジュール）は、入荷や出荷、棚卸など複数の機能から共通に使われます。このようなモジュールの場合、特定の機能仕様書内に仕様を記述するのは好ましくないので、モジュール単体で機能仕様書を作成します。

テスト仕様書とテスト結果報告書

   テスト工程におけるドキュメントは、「テスト仕様書」と「テスト結果報告書」です。テスト仕様書はテスト前に作成するもので、どのようなテストを行い、どういう結果となればよいかを記述します。テストの結果は、テスト結果報告書としてまとめられます。基本的にテスト項目に対して、その結果を記載していくので、テスト仕様書とテスト結果報告書は対比します。そのため、DUNGEONではこの2つを別々に作成するのではなく、1つのドキュメントとしてまとめています。

単体テスト仕様書

   詳細設計書に記載されている内容が正しく動作することを確認することが単体テストです。そんなことは当たり前と思われるでしょうが、実際はその通りになっていないことが多くあります。

   上記aは、詳細設計書に書かれているのにテスト項目から漏れてしまったり、単体テスト仕様書をろくに作成せずにテストするような場合です。

   逆にcのように詳細設計書の記載漏れを単体テストでカバーしようとするケースも注意が必要です。ろくに設計書を作成しないでプログラミングを行うような場合も、これに該当します。「設計書の不備をテストでカバーする」という考え方は、何を持って正常と判断するかの基準があいまいになり、多くの場合にバグ発生の原因となります。

   このような観点から、単体テスト仕様書は、詳細設計書と対比したフォーマットとなります。DUNGEONのように詳細設計書のフォーマット化を推進した場合は、単体テスト仕様書もフォーマット化が可能となります。しかし、詳細設計書が自由記述であれば単体テスト仕様書も自由記述的なものになります。