「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？：誰にでも分かるSEのための文章術（11）（1/2 ページ）

「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。

[谷口功，＠IT]

　メーカーが機械を納入する際は、耐久試験や性能試験などの結果を添付して、問題がないことを顧客に確認してもらいます。同様にシステム開発においても、テスト結果を顧客に提示してシステムに問題がないことを確認してもらう必要があります。

　今回と次回の2回にわたって、「テスト仕様書」の書き方と表現のポイントを説明します。

　今回は、「顧客にとって良いテスト仕様書」とは何か、「顧客にとって良いテスト仕様書」にするためには何を記述すればよいのか、テスト仕様書のおおまかな内容と構成を説明します。次回は、どのように表現すればよいのか、文章の具体的な表現ポイントを説明します。

テスト仕様書の全体像

　システムのテストには、単体テスト、結合テスト、システムテスト、運用テストなどがあります。それぞれのテストは開発工程に対応しています。

要件定義     --------------------     運用テスト
    ↓                                     ↑
外部設計     --------------------     システムテスト
    ↓                                     ↑
内部設計     --------------------     結合テスト
    ↓                                     ↑
コーディング --------------------     単体テスト

　それぞれのテストは、次のような意味を持ちます。

• 単体テスト……プログラミングの成果を検査するテスト
• 結合テスト……内部設計の仕様を満たしていることを確認するテス
• システムテスト……外部設計の仕様を満たしていることを確認するテスト
• 運用テスト……要件定義を満たしていることを確認するテスト

　これらのテストのうち、顧客に関係するのは「運用テスト」です。

　顧客は、開発作業において「要件定義」の段階で関与します。顧客がシステムに求めるものすべてが、要件定義書に記述されています。顧客にとって最も重要なことは「要件定義書を満たしているかどうか」を確認することです。そのため、「運用テストのテスト仕様書」は、顧客に向けて作成しなければなりません。

　一般的に、テスト仕様書（またはテスト項目表、テストケース）は、開発プロジェクト内部で流通させることを念頭に置いています。しかし、運用テストのテスト仕様書は、技術者のためだけでなく、顧客のための文書であることが必要です。

顧客にとって「良いテスト仕様書」とは？

　“顧客のための”テスト仕様書にするためには、顧客視点でテスト仕様書を考えることが重要です。そこで、まずは「技術者にとって良いテスト仕様書」と「顧客にとって良いテスト仕様書」の違いについて考察してみましょう。

技術者にとって良いテスト仕様書

　SEやプログラマにとって、「テスト」はできるだけ多くのバグを発見・修正し、問題点を解決することによってシステムを高品質にするための作業です。そこで、技術者はテスト仕様書を「バグ発見・修正を管理するために必要な文書」と考えます。技術者にとって良いテスト仕様書は、「バグの発見と修正の管理のために使いやすい文書」です。

顧客にとって良いテスト仕様書

　一方、顧客にとっての「テスト仕様書の位置付け」は異なります。顧客にとってテスト仕様書は、「要件定義書で決めた事項が満たされたシステムになっているかどうか、導入前にチェックして確認するための文書」です。顧客側は、主に下記のようなことを確認したいと考えるでしょう。

• 求める機能や性能が要求どおりの品質になっていること
• 業務作業に支障ない使い勝手やユーザーインターフェイスになっていること
• システムを導入するメリット（業務効率の改善、導入前より業務作業がやりやすくなるなど）が達成されていること

　顧客にとって良いテスト仕様書とは、「システムがきちんと完成していることが簡単に確認できる文書」です。テスト仕様書は、開発側の視点と顧客の視点、両方から見て満足できるものにしなければなりません。

バグ数やステップ数なんて顧客には関係ない？ テスト項目の作り方

　「顧客にとって良いテスト仕様書」にするために、顧客が求めるものを基準にしてテスト項目を設定しましょう。

　開発側の視点で考えると、テストの目標を“定量的”にとらえがちです。技術者は、プログラムのステップ数、バグの数、テストでチェックする項目の数などを基準にして、テスト目標を設定します。「テスト項目数を100抽出する」「プログラム100ステップについて最低1つのバグを見つけ出す」「チェック項目10件について最低1つのバグを見つけ出す」……などです。

　一方、顧客にとってのテスト目標は、「要件定義書の定義事項がすべて満たされているかどうかの確認」です。

　そこで、テスト項目は、単純に定量的な基準で設定するのではなく、要件定義書の定義事項をすべてチェックできるように設定しましょう。「数値の基準が満たされているからそれでよし」とするのではなく、顧客の求めるものがすべて満たされていることをゴールとして設定しなければいけません。

一目で分かるテスト仕様書は「項目対応」が命！

　テスト項目は、要件定義書に記述した定義事項と対応していなければなりません。つまり、「このテスト項目は、要件定義書のどの定義事項を確認するためのものか」、顧客が把握できるようにする必要があります。

　ただし、顧客に負担を負わせてはいけません。顧客が一目見ただけで簡単に、テスト項目と要件定義書の定義事項の対応を把握できるようにしましょう。複雑な対応関係にしないことが重要です。

　さらに、顧客が「テスト項目の網羅性」を認識できることも必要です。つまり、「テスト仕様書のテスト項目を実施すれば、要件定義書の定義事項をすべて確認できる」ことを、顧客に納得してもらえる文書になっているようにしましょう。

　では、具体的にどのようにすればよいのでしょうか。「納得してもらえる」文書にするためには、テスト仕様書の構成を要件定義書の階層構成（大見出し−中見出し−小見出しの構成）と同一にし、さらに各項目のタイトルも同一にするのが最善ではないでしょうか。こうすれば、顧客は一目で分かります。

　そして、要件定義書における最下位の階層（一般的には小見出しやある機能の要件定義など）を、1つまたは複数のテスト項目で構成します。このとき、1つのテスト項目のテスト内容は1つの操作で表します。つまり、これは「1つの操作で表せるようにテスト項目を抽出しなければならない」ということです。