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