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

2005年9月9日(金)
梅田 弘之(うめだ ひろゆき)

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


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

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

  1. テストの種類と方法までにとどめる
  2. 項目ごとにテスト内容を細かく記述
   例えば、「受注入力」の単体テストで必須チェック(画面の項目に値を入れない状態で更新ボタンを押した場合のエラーチェック)を行う場合を考えます。

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

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

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

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

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

単体テスト仕様書(画面用)
図2:単体テスト仕様書(画面用)
(画像をクリックするとExcelファイルをダウンロードできます。/31.5KB)

単体テスト仕様書(帳票用)
図3:単体テスト仕様書(帳票用)
(画像をクリックすると別ウィンドウに拡大図を表示します)

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


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

DUNGEON標準テンプレートをプロジェクトごとにカスタマイズ
図4:DUNGEON標準テンプレートをプロジェクトごとにカスタマイズ

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

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

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

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

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

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


まとめ


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

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

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

著者
梅田 弘之(うめだ ひろゆき)
株式会社システムインテグレータ

東芝、SCSKを経て1995年に株式会社システムインテグレータを設立し、現在、代表取締役社長。2006年東証マザーズ、2014年東証第一部、2019年東証スタンダード上場。

前職で日本最初のERP「ProActive」を作った後に独立し、日本初のECパッケージ「SI Web Shopping」や開発支援ツール「SI Object Browser」を開発。日本初のWebベースのERP「GRANDIT」をコンソーシアム方式で開発し、統合型プロジェクト管理システム「SI Object Browser PM」など、独創的なアイデアの製品を次々とリリース。

主な著書に「Oracle8入門」シリーズや「SQL Server7.0徹底入門」、「実践SQL」などのRDBMS系、「グラス片手にデータベース設計入門」シリーズや「パッケージから学ぶ4大分野の業務知識」などの業務知識系、「実践!プロジェクト管理入門」シリーズ、「統合型プロジェクト管理のススメ」などのプロジェクト管理系、最近ではThink ITの連載をまとめた「これからのSIerの話をしよう」「エンジニアなら知っておきたいAIのキホン」「エンジニアなら知っておきたい システム設計とドキュメント」を刊行。

「日本のITの近代化」と「日本のITを世界に」の2つのテーマをライフワークに掲げている。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています