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

トンデモな使い方をする可能性を考慮して項目を作成せよ

　テスト項目は、顧客が求めるものをすべて満たすように設定するだけでは十分ではありません。テスト項目は、“顧客が気付かない”ところまで考慮している必要があります。

　要件定義書では、正常な使い方におけるシステムの機能、性能を定義します。使い方を間違えていたり、例外的な操作をしたときの定義は記述してありません。要件定義の段階において、顧客がシステムに求めるものは、あくまで正常な使い方や操作をした際の機能・性能です。それ以外については考慮しない顧客が多いでしょう。

　しかし、実際にシステムを稼働させた後、必ず誤った使い方をする人は出てきます。その際にエラーが生じれば、顧客は苦情を申し立ててくるでしょう。そこで、誤った使い方や操作については、開発側でフォローしなければなりません。

　テスト項目には、正常な操作のケースだけでなく、誤った操作や例外的な操作のケースも設定しておきます。そのため、技術者はシステムが使われるあらゆるケース、あらゆるユーザーの振る舞いを仮定して、それらを網羅できるようにテスト項目を設定することが必要です。

序論と結論の記述

　テスト仕様書を分かりやすくするためには、先頭に「テスト概要」を記述しておきましょう。概要は、いわゆる5W1Hを念頭に記述すればよいでしょう。

序論の記述

• What：何をテストするのか＝顧客に納入するシステム
• Why：何のためのテストであるのか＝要件定義書で定義した事項を確認するため
• When：運用テストの時期やスケジュール
• Where：運用テストを行う場所や環境（顧客の業務環境を使ってテストするケースもある）
• Who：テストを実行する担当者（顧客の業務担当者にお願いするケースもある）
• How：運用テストのやり方。顧客に提供する操作マニュアルに記述された手順に従ってテストを実行する場合は、その旨を記述する

結論の記述

　テスト仕様書の終わりには、まとめの報告を記述します。まとめの報告は、テストが完了しているのであれば特に問題はありません。テスト結果に問題がないことを報告すればよいだけです。

　しかし、世の中はそううまくいきません。テスト中に検出したバグの修正が完了せず、未解決のバグが残ってしまったテスト項目が存在する場合があります。この場合は「未解決のテスト項目について、今後きちんと対応する」ことを、分かりやすく顧客に伝えなければなりません。単に数値的な情報、バグ残余率（バグ消化率）やバグ密度などを報告するだけでは、顧客の納得を得られません。ここでは、バグが修正できなかったテスト項目ごとに、次のような事項を記述します。

• 問題の原因・理由
• システムのどの機能や性能に、どのような影響があるのか
• どのような方針で、どのような対応をするのか
• どのような方法で改善するのか
• いつまでに対応するのか

　もし改善が顧客の稼働開始に間に合わないのであれば、バグを避けながら同等の機能・性能を確保できるような代替の手段や手順を記述します。

テスト仕様書はマニュアルと整合性を取っておく

　運用テストは、顧客のユーザーが業務でシステムを使用し、実際に操作するときと同じ状態でテストすることになります。

　ユーザーが業務でシステムを使用・操作するための指針として、顧客には操作マニュアルを提供します。そのため、各テスト項目における操作手順は、マニュアルの内容と整合性が取れている必要があります。

　運用テスト時に操作マニュアルがすでに出来上がっているのであれば、それを使ってテストします。テスト仕様書のテスト項目における操作手順欄では、マニュアルの該当個所（項目タイトルやページ番号など）に言及しておきましょう。

　もし、テスト時点で操作マニュアルが出来上がっていないのであれば、テストで行った操作手順をマニュアルの作成工程に引き継いでおきましょう。