業務システムの開発ドキュメント標準化 第６回：単體テスト仕様書＆報告書

設計＆テストのＶ字モデル

   一般にウォーターフォール型開発におけるテストは、図1のようなV字モデルで表されます。DUNGEONは、このV字モデルにのっとった設計＆テスト體系を採っています。

   つまり、次のように要求分析と総合テスト、基本設計と結合テスト、詳細設計と単體テストを対比させ、各テストでは対応する設計書の內容を満たすことを確認するのです。

図1：設計＆テストのV字モデル

   ここで各設計工程における定義內容を整理しておきましょう。

要求分析と総合テスト

   要求分析では、ユーザの業務要件を定義します。例えば受注業務であれば、次のような業務の流れが業務要件となります。

1. 客先からの註文書を受け、その內容を受注入力する
2. 受注入力した內容は伝票に出力される。印刷される伝票は、註文請書と註文伝票の2枚で、註文請書は客先に提出され、註文伝票は営業事務でファイリングする
3. 受注の際、在庫があれば在庫に、在庫がなければ発注殘に引き當てる。在庫も発注殘もない場合は、営業擔當者に判斷を仰ぎ、発注依頼にまわすことができる

   DUNGEONでは、このような業務要件を本連載の第1回で説明した「業務フロー」というドキュメントに記載します。全體を通した業務の流れ、部署ごとの業務の役割、業務に使う畫面や帳票などの種類を業務フローに図示し、上記のような業務要件を説明欄に記載するのです。

   総合テストでは、実運用に近い狀態でシステムが有効に機能することを確認します。本番同様のデータを使い、要求分析で定めた業務の手順にそってシステムを使って業務をまわします。うまく運用がまわるか、不都合はないかということをシステムおよび運用の両面に渡って確認するのです。

基本設計と結合テスト

   基本設計ではユーザの機能要件が定義されています。例えば、受注入力畫面という機能であれば、どのような項目を入力するか、どのような畫面レイアウトになっているか、各項目の入力文字數や入力文字種類など、ユーザから見た場合の機能について定義されます。

   結合テストは、これらの機能を組み合わせた一連の流れをテストします。例えば受注処理では、「受注入力」機能で註文データを入力し、「受注伝票」を印刷する。その結果「在庫引當」が行われて有効在庫が減る。そういう一連の処理を「在庫照會」や「在庫一覧表」などの畫面／帳票を使いながら確認するのです。

業務システムにおけるV字モデルとの不一致

   DUNGEONは、基本的に業務システムを構築するためのドキュメント標準ですが、いわゆるV字モデルとピッタリ合っていません。それは、基本設計で"機能"単位に設計書が作成されるのに対し、結合テストは"複數の機能"の組み合わせでテストするものと定義している點です。

   業務システムにおける結合テストは、例えば受注から出荷指示、出荷、売上など一連の業務を通してテストし、その流れの中で畫面や帳票を出力してデータの整合性を確認することが主となります。つまり、本番直前の総合テストと同じようなテスト內容ではあるが、テスト用データを使って開発環境で行うという位置づけにしているのです。

   この不一致は、詳細設計や単體テストの対象単位を"モジュール"ではなく"機能"にしているから生じます。前回説明したビジネスロジックのようなモジュール単位に単體テストを行い、複數のモジュールを組み合わせた機能単位に結合テストを行うと定義すればV字モデルに合致するのですが、この用法は、業務システムには適さないと考えています。

詳細設計と単體テスト

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

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

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

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

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

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

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

単體テスト仕様書

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

1. 詳細設計書＞単體テスト仕様書
2. 詳細設計書＝単體テスト仕様書
3. 詳細設計書＜単體テスト仕様書

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

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

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

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

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

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

1. テストの種類と方法までにとどめる
2. 項目ごとにテスト內容を細かく記述

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

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

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

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

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

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

図2：単體テスト仕様書（畫面用）
（畫像をクリックするとExcelファイルをダウンロードできます。/31.5KB）

図3：単體テスト仕様書（帳票用）
（畫像をクリックすると別ウィンドウに拡大図を表示します）

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

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

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

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

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

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

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

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

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

まとめ

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

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

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