業務システムの開発ドキュメント標準化 第６回：単体テスト仕様書＆報告書
|
設計＆テストのＶ字モデル |
|
ここで各設計工程における定義内容を整理しておきましょう。 |
|
要求分析と総合テスト |
|
|
|
|
|
DUNGEONでは、このような業務要件を本連載の第1回で説明した「業務フロー」というドキュメントに記載します。全体を通した業務の流れ、部署ごとの業務の役割、業務に使う画面や帳票などの種類を業務フローに図示し、上記のような業務要件を説明欄に記載するのです。 |
|
基本設計と結合テスト |
|
|
|
|
|
業務システムにおけるV字モデルとの不一致 |
|
|
| 詳細設計と単体テスト |
|
DUNGEONでは、"機能"単位に詳細設計書が作成されます。前回、詳細設計書について解説しましたが、そのテンプレートに示すように、"機能"には複数のモジュールが含まれます。 例えば、「プロスペクト一覧」という機能は、「プロスペクト一覧」という画面と「プロスペクト検索」「プロスペクト印刷」「月別受注見込出力」という3つのビジネスロジックの合計4モジュールから構成されます。 |
|
共通モジュールの設計書は単独で DUNGEONでは、モジュール単位ではなく、機能単位で詳細設計書を作成します。これは、モジュール単位だと設計書が細分化され過ぎて機能要件が把握し難くなると考えているからです。そのため、機能に含まれるモジュールの仕様は、機能設計書の中に含んで記述されます。 しかし、モジュールの中には複数の機能で共通に使われるモジュールが存在します。例えば、「在庫更新」というビジネスロジック（モジュール）は、入荷や出荷、棚卸など複数の機能から共通に使われます。このようなモジュールの場合、特定の機能仕様書内に仕様を記述するのは好ましくないので、モジュール単体で機能仕様書を作成します。 |
| テスト仕様書とテスト結果報告書 |
|
テスト工程におけるドキュメントは、「テスト仕様書」と「テスト結果報告書」です。テスト仕様書はテスト前に作成するもので、どのようなテストを行い、どういう結果となればよいかを記述します。テストの結果は、テスト結果報告書としてまとめられます。基本的にテスト項目に対して、その結果を記載していくので、テスト仕様書とテスト結果報告書は対比します。そのため、DUNGEONではこの2つを別々に作成するのではなく、1つのドキュメントとしてまとめています。 |
| 単体テスト仕様書 |
|
詳細設計書に記載されている内容が正しく動作することを確認することが単体テストです。そんなことは当たり前と思われるでしょうが、実際はその通りになっていないことが多くあります。
|
|
上記aは、詳細設計書に書かれているのにテスト項目から漏れてしまったり、単体テスト仕様書をろくに作成せずにテストするような場合です。 逆にcのように詳細設計書の記載漏れを単体テストでカバーしようとするケースも注意が必要です。ろくに設計書を作成しないでプログラミングを行うような場合も、これに該当します。「設計書の不備をテストでカバーする」という考え方は、何を持って正常と判断するかの基準があいまいになり、多くの場合にバグ発生の原因となります。 このような観点から、単体テスト仕様書は、詳細設計書と対比したフォーマットとなります。DUNGEONのように詳細設計書のフォーマット化を推進した場合は、単体テスト仕様書もフォーマット化が可能となります。しかし、詳細設計書が自由記述であれば単体テスト仕様書も自由記述的なものになります。 |
| 単体テスト仕様書の記述度 |
|
単体テスト仕様書を作成する際に、どの程度まで細かく記述するかの方針を立てる必要があります。 下記Aは、やらなければならないテストの種類と方法だけを記載し、どの項目をどのような値でテストするかという具体的な内容はテスト者に任せる方法です。一方Bは、項目ごとにどんな値を入れて、どうなればよいかを細かく記述する方法です。
|
|
例えば、「受注入力」の単体テストで必須チェック（画面の項目に値を入れない状態で更新ボタンを押した場合のエラーチェック）を行う場合を考えます。 Aの方法は"必須チェック"というテスト種類を記載するにとどめ、どの項目が必須チェック対象かまではテスト仕様書に書き出しません。 それらは詳細設計書に記載されているので、そちらを参考にしながらテストすればよいという考え方なのです。テスト仕様書の作成工数は削減できますが、テスト実施者のスキルに依存する部分が大きくなります。 一方Bの方法は、必須チェックの対象項目やどんな値を入れて確認するかなどを細かくテスト仕様書に書き出します。設計書と突合せする必要はなくテスト実施者のスキル依存度も低くなりますが、単体テスト仕様書の作成作業が膨大になります。 単体テスト仕様書をどちらの方針で作成するかは、対象アプリケーションにより異なります。Webシステムなど比較的入力項目の少ないアプリケーションであればB方式も可能ですが、大規模な基幹業務システムのように項目が多い場合はA方式にとどめておいた方が無難です。 DUNGEONでは標準的なドキュメントを定義することしかできませんので、A方式のみサポートしています。図2と図3は、DUNGEONで提供する単体テスト仕様書のドキュメントテンプレートです。 図2：単体テスト仕様書（画面用） （画像をクリックするとExcelファイルをダウンロードできます。/31.5KB）  図3：単体テスト仕様書（帳票用） （画像をクリックすると別ウィンドウに拡大図を表示します） |
| テンプレートのカスタマイズ |
|
図4：DUNGEON標準テンプレートをプロジェクトごとにカスタマイズ 図2および図3の単体テスト仕様書では、分類ごとに試験・確認項目を洗い出し、その試験内容を簡単に記載しています。 例えば図2のカーソルという分類では、試験番号3-1でTabキーによるカーソル移動と戻りが正常かどうかテストすることが書かれています。A方式なのでテストの種類を定義しているだけで、どの項目からどの項目に移動すべきかという具体的な内容は記載していません。それらは詳細設計書に記載してあり、その通りに動作することの確認テストを忘れないことが重要なのです。 図2、図3には、該当欄があります。テスト対象の機能に対してテスト項目が該当する場合に「○」をつけ、その部分だけをテストすることになります。該当欄の代わりに、該当しないテスト項目を行単位に削除して使用してもかまいません。 テストを行って正常だった場合は、右端の確認欄に「○」を入れます。問題がある場合は「×」を記入して、その内容を別途、障害報告書に記載するような運用を想定しています。 プロジェクト標準を定める際の方針で、「○」「×」だけでなく、テスト実施者や実施日などを記入する様式にしてもかまいません。いずれにしても、テスト結果も記載することで、テスト結果報告書として提出できるドキュメントになるのです。 |
| まとめ |
|
今回は、テスト仕様書とテスト結果報告書について説明しました。 テストのV字モデルを踏まえた上で、設計書とテストがどのように対比するかという考え方も理解できたと思います。DUNGEONのドキュメントテンプレートとしては、「単体テスト仕様書」を取り上げました。テスト種類の漏れをなくすという目的で、一般的な画面や帳票のテスト項目を網羅しているので、これを各プロジェクト用にカスタマイズして使ってください。 次回は、残りのテストである「結合テスト」と「総合テスト」について説明します。 |