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

単体テスト仕様書の記述度

   単体テスト仕様書を作成する際に、どの程度まで細かく記述するかの方針を立てる必要があります。

   下記Aは、やらなければならないテストの種類と方法だけを記載し、どの項目をどのような値でテストするかという具体的な内容はテスト者に任せる方法です。一方Bは、項目ごとにどんな値を入れて、どうなればよいかを細かく記述する方法です。

   例えば、「受注入力」の単体テストで必須チェック（画面の項目に値を入れない状態で更新ボタンを押した場合のエラーチェック）を行う場合を考えます。

   Aの方法は"必須チェック"というテスト種類を記載するにとどめ、どの項目が必須チェック対象かまではテスト仕様書に書き出しません。

   それらは詳細設計書に記載されているので、そちらを参考にしながらテストすればよいという考え方なのです。テスト仕様書の作成工数は削減できますが、テスト実施者のスキルに依存する部分が大きくなります。

   一方Bの方法は、必須チェックの対象項目やどんな値を入れて確認するかなどを細かくテスト仕様書に書き出します。設計書と突合せする必要はなくテスト実施者のスキル依存度も低くなりますが、単体テスト仕様書の作成作業が膨大になります。

   単体テスト仕様書をどちらの方針で作成するかは、対象アプリケーションにより異なります。Webシステムなど比較的入力項目の少ないアプリケーションであればB方式も可能ですが、大規模な基幹業務システムのように項目が多い場合はA方式にとどめておいた方が無難です。

   DUNGEONでは標準的なドキュメントを定義することしかできませんので、A方式のみサポートしています。図2と図3は、DUNGEONで提供する単体テスト仕様書のドキュメントテンプレートです。

   フォーマットだけではなく、一般的なアプリケーションで考えられるテスト項目を画面と帳票に分けて用意しています。

テンプレートのカスタマイズ

   図4のように、まずこのテンプレートをそのプロジェクトに合うようにカスタマイズし、プロジェクトにおけるテスト仕様書の雛形を作成します。そして、それをテンプレートとして、画面や帳票など機能単位に単体テスト仕様書を作成するという2段階の手順になります。

   図2および図3の単体テスト仕様書では、分類ごとに試験・確認項目を洗い出し、その試験内容を簡単に記載しています。

   例えば図2のカーソルという分類では、試験番号3-1でTabキーによるカーソル移動と戻りが正常かどうかテストすることが書かれています。A方式なのでテストの種類を定義しているだけで、どの項目からどの項目に移動すべきかという具体的な内容は記載していません。それらは詳細設計書に記載してあり、その通りに動作することの確認テストを忘れないことが重要なのです。

   図2、図3には、該当欄があります。テスト対象の機能に対してテスト項目が該当する場合に「○」をつけ、その部分だけをテストすることになります。該当欄の代わりに、該当しないテスト項目を行単位に削除して使用してもかまいません。

   テストを行って正常だった場合は、右端の確認欄に「○」を入れます。問題がある場合は「×」を記入して、その内容を別途、障害報告書に記載するような運用を想定しています。

   プロジェクト標準を定める際の方針で、「○」「×」だけでなく、テスト実施者や実施日などを記入する様式にしてもかまいません。いずれにしても、テスト結果も記載することで、テスト結果報告書として提出できるドキュメントになるのです。

まとめ

   今回は、テスト仕様書とテスト結果報告書について説明しました。

   テストのV字モデルを踏まえた上で、設計書とテストがどのように対比するかという考え方も理解できたと思います。DUNGEONのドキュメントテンプレートとしては、「単体テスト仕様書」を取り上げました。テスト種類の漏れをなくすという目的で、一般的な画面や帳票のテスト項目を網羅しているので、これを各プロジェクト用にカスタマイズして使ってください。

   次回は、残りのテストである「結合テスト」と「総合テスト」について説明します。