第12回 知るだけで天地の差が出る、テスト仕様書の必須項目&表現方法
谷口 功
2010/8/25
| 「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 |
| エンジニアライフ コラムニスト募集中! |
あなたも@ITでコラムを書いてみないか 自分のスキル・キャリアの棚卸し、勉強会のレポート、 プロとしてのアドバイス……書くことは無限にある! コードもコラムも書けるエンジニアになりたい挑戦者からの応募、絶賛受付中 |
第11回「『バグ数には興味ないのだよ』――顧客が喜ぶテスト仕様書とは?」では、顧客にとって良いテスト仕様書にするためには、何を記述すればよいのかについて、「全体的な内容と構成」を説明しました。
今回は、良い仕様書にするためにはどう表現すればよいのか、「具体的な表現ポイント」を説明します。
■テスト仕様書で絶対に必要な項目リスト
テスト仕様書に記述すべきものとして、以下の事項があります。
- テストを実施した環境
- 実施するテストの内容
- テストを実施するためのシステムの操作手順
- テストの実行結果
- 個々のテスト項目を識別するための番号や記号(通し番号など)
- テストを実施した年月日
- テストを実行した担当者
- 障害報告票番号(発生した障害の詳細を開発グループに報告する帳票の識別番号)
■まずはテスト環境について明記する
テスト仕様書の先頭には、「テストを実施した環境」を記述します。ここでは、ハードウェア環境やソフトウェア環境、ネットワーク環境など、「どのような環境でテストを行ったか」を説明します。
ただし、テストを実施した環境を記述するだけでは十分ではありません。「顧客にとって必要な情報は何か」を考えるのです。ここで必要なのは、「要件定義書で規定した環境」との関係が分かることです。
なぜなら、顧客が業務を行うのは、要件定義書で規定したシステム構成に基づく環境だからです。顧客にとっては、「要件定義書で規定した環境でシステムがきちんと動作するかどうか」が重要です。規定とは異なる環境で実施したテスト結果であれば、十分に信頼できないでしょう。
要件定義書が規定した環境でテストした場合は、そのことを明記したうえでテスト環境を具体的に記述しましょう。要件定義書の環境と異なる環境(例えば、簡易化した環境)でテストした場合は、以下の点に留意する必要があります。
- テストを実施した環境を具体的に明示する
- テスト実施環境と業務遂行時の環境との差異を明確にする
- 両者の差異はシステムの動作に影響を与えないと断言する
例えば次のように記述して、テスト実施環境が納得できるものであることを、顧客に理解してもらいます。
|
テストを実施したシステム環境を別紙に示します。今回のテスト環境は、実際の業務時の環境とは以下のような点が異なります。
(1)…… (2)…… しかし、これらの点はシステムのテスト結果には影響を与えません。今回のテスト環境で正常に動作すれば、実際の業務環境でも正常に動作します。 |
また、テスト段階で、顧客が業務で使用するときとは異なる前提条件が必要なケースがあります。この場合は、前提条件を明示するとともに、その条件がシステムのテスト結果には無関係であることを断言しましょう。例えば、次のように記述します。
| このようにテスト実施に際して前提とした条件がありますが、それらはシステムの動作には無関係であり、テスト結果に影響を与えることはありません。 |
■「たかがタイトル、されどタイトル」――テスト項目の名付け方
先ほど、テスト仕様書に記述すべきものとして(1)〜(8)の項目を挙げました。これらの項目のタイトルは、できるだけ顧客に分かりやすい名前を付けてください。
ささいなことのように思えますが「たかがタイトル、されどタイトル」です。例えば、開発プロジェクトの内部で流通させるテスト仕様書では、I のようなタイトルをよく使うのではないでしょうか。しかし、顧客がテスト仕様書に求めるものは「システムの完成度を確認すること」です。その点を考慮すると、II のタイトルの方が適切です(※ただし「障害報告票番号」については後述)。
●タイトル例 I
- 実施するテストの内容……テスト内容
- テストを実施するためのシステムの操作手順……テスト手順
- テストの実行結果……テスト結果
- 個々のテスト項目を識別するための番号や記号(通し番号など)……項番
- テストを実施した年月日……実施日
●タイトル例 II
- 実施するテストの内容……テスト内容 → 確認内容
- テストを実施するためのシステムの操作手順……テスト手順 → 操作手順
- テストの実行結果…… テスト結果 → 確認結果
- 個々のテスト項目を識別するための番号や記号(通し番号など)……項番 → テスト項目番号
- テストを実施した年月日……実施日 → 確認日
- テストを実行した担当者……実施者 → 確認者
テスト仕様書のフォーマットは、次のようになります。
| テスト項目番号 | 確認内容 | 操作手順 | 確認結果 | 確認日 | 確認者 | 障害報告票番号 |
| あなどるなかれ、確認結果の表記方法 | |
誰にでも分かるSEのための文章術 バックナンバー
- 第1回 開発工程でSEが書く文書の基本
- 第2回 ヒアリング現場で使えるコミュニケーション力
- 第3回 分かりやすい提案書はアウトラインが美しい
- 第4回 「要件定義書のアウトライン作成」完全マニュアル
- 第5回 ドキュメントの質を確実に上げる6つの文章作法
- 第6回 読みやすい文章の極意は「修飾語」にあり
- 第7回 専門用語は徹底的に「読み手指向」で書くべし
- 第8回 さらば、翻訳調の文章! 技術者のための校正ルール
- 第9回 文書ごとに最適な「構成のフレームワーク」は異なる
- 第10回 論理的プログラムを書くPGは論理的な文章も書ける?
- 第11回 「バグ数に興味ない」 顧客が喜ぶテスト仕様書とは?
- 第12回 知るだけで天地の差?テスト仕様書の項目&表現法
- 第13回 「目次」の良し悪しが、マニュアルの良し悪しを決める
- 第14回 マニュアル執筆が怖くなくなる、12の執筆ポイント
- 第15回 開発を成功させたいSEに送る「執筆のおきて」まとめ
|
|
| スキルアップに役立つ問題を無料で出題 | |
| ITスキル研修4000件、最新情報の検索できます |
キャリアアップ
スポンサーからのお知らせ
・ケ・ュ・チマツ、クヲオ貍シ・ケ・ン・・オ。シ
- - PR -


点数に応じてレベル認定、PHP技術者認定上級試験が開始へ