テスト項目は、顧客が求めるものをすべて満たすように設定するだけでは十分ではありません。テスト項目は、“顧客が気付かない”ところまで考慮している必要があります。
要件定義書では、正常な使い方におけるシステムの機能、性能を定義します。使い方を間違えていたり、例外的な操作をしたときの定義は記述してありません。要件定義の段階において、顧客がシステムに求めるものは、あくまで正常な使い方や操作をした際の機能・性能です。それ以外については考慮しない顧客が多いでしょう。
しかし、実際にシステムを稼働させた後、必ず誤った使い方をする人は出てきます。その際にエラーが生じれば、顧客は苦情を申し立ててくるでしょう。そこで、誤った使い方や操作については、開発側でフォローしなければなりません。
テスト項目には、正常な操作のケースだけでなく、誤った操作や例外的な操作のケースも設定しておきます。そのため、技術者はシステムが使われるあらゆるケース、あらゆるユーザーの振る舞いを仮定して、それらを網羅できるようにテスト項目を設定することが必要です。
テスト仕様書を分かりやすくするためには、先頭に「テスト概要」を記述しておきましょう。概要は、いわゆる5W1Hを念頭に記述すればよいでしょう。
テスト仕様書の終わりには、まとめの報告を記述します。まとめの報告は、テストが完了しているのであれば特に問題はありません。テスト結果に問題がないことを報告すればよいだけです。
しかし、世の中はそううまくいきません。テスト中に検出したバグの修正が完了せず、未解決のバグが残ってしまったテスト項目が存在する場合があります。この場合は「未解決のテスト項目について、今後きちんと対応する」ことを、分かりやすく顧客に伝えなければなりません。単に数値的な情報、バグ残余率(バグ消化率)やバグ密度などを報告するだけでは、顧客の納得を得られません。ここでは、バグが修正できなかったテスト項目ごとに、次のような事項を記述します。
もし改善が顧客の稼働開始に間に合わないのであれば、バグを避けながら同等の機能・性能を確保できるような代替の手段や手順を記述します。
運用テストは、顧客のユーザーが業務でシステムを使用し、実際に操作するときと同じ状態でテストすることになります。
ユーザーが業務でシステムを使用・操作するための指針として、顧客には操作マニュアルを提供します。そのため、各テスト項目における操作手順は、マニュアルの内容と整合性が取れている必要があります。
運用テスト時に操作マニュアルがすでに出来上がっているのであれば、それを使ってテストします。テスト仕様書のテスト項目における操作手順欄では、マニュアルの該当個所(項目タイトルやページ番号など)に言及しておきましょう。
もし、テスト時点で操作マニュアルが出来上がっていないのであれば、テストで行った操作手順をマニュアルの作成工程に引き継いでおきましょう。
谷口 功 (たにぐち いさお)
フリーランスのライター、翻訳家。企業にて、ファクシミリ通信網を使ったデータ通信システム、人工知能、日本語処理関連のソフトウェア開発、マニュアルの執筆などに関わる。退職後、コンピュータ、情報処理、通信関連の書籍の執筆、翻訳、各種マニュアルや各種教材の執筆に携わる。また、通信、コンピュータ関連のメールマガジンの記事、各種雑誌においてインターネット、パソコン関連の記事やコラムなども執筆。コンピュータや通信に関連する漫画の原作を執筆することもある。 主な著作は、『SEのための 図解の技術、文章の技術』(技術評論社)、『ソフト契約と見積りの基本がよ〜くわかる本』『よくわかる最新 通信の基本と仕組み』(秀和システム)、『図解 通信プロトコルのことがわかる本』『入門ビジュアルテクノロジー 通信プロトコルのしくみ』(日本実業出版社)、『図解 ネットワークセキュリティ』『マスタリングTCP/IP IPsec編』[共著](オーム社)など。
Copyright © ITmedia, Inc. All Rights Reserved.