検証エキスパートコラム

みなさん、こんにちは。
テスト仕様書の作り方大公開の第３回です。前回(blog-No.38)はテスト条件一覧の「機能と観点」についてご説明しました。今度は期待値、つまり「どういう結果になっていればＯＫなのか？」を記述していきます。
それとともに、ついついやってしまう、ありがちな失敗例についても触れてみたいと思います。

 

期待値は具体的な値を設定する

確認項目と違って、期待値の欄は『具体的な値』でなければなりません。そうでないと、結果の良し悪しが判定できなかったり人によって判定結果がブレたりして、客観的な判断ができなくなります。

良い例）
・ステータスが「1」であること
・画面に表示された内容とDBに登録された内容が一致していること
ダメな例）
・集計が正しいこと（←何をもって「正しい」というかが不明）
・ダウンロードが問題なく行えること（←「問題なく」とはどういう状態かが不明）

ただし、必ずしも固定値でなくてもよく、「第三者が客観的に識別できる」値であればよいです。
例）
・表示順が氏名（カナ）の昇順であること
・金額が[単価]×[数量]であること

時には包括的な表現をせざるを得ないケースもありますが、その場合は別途客観的な基準を定めておくことが肝要です。
例）
・表示崩れがないこと（←どの程度まで許容するか？）
・誤字脱字がないこと（←何に従うのか？）

 

やってしまいがちな3つの失敗

立場上、テスト仕様書をレビューすることが多いのですが、次のような失敗例が散見されます。
特に、開発担当者がそのままテスト設計を行っているケースによく見られるようです。

①操作手順が必要以上に詳しく書いてある
【原　因】「テスト＝操作すること」という概念にとらわれている
【リスク】手順の消化に終始し、テストの目的を見失う
【対　策】操作手順は別紙で説明し、テスト仕様書はあくまで「どんなテストをするか」に徹すること

②確認項目と期待値に同じことしか書いていない
【原　因】何を確認すべきかまとまっていない、または仕様確認不足で結果が想定できていない
【リスク】確認すべき事項が不明確になり、結果の合否判定を誤る
【対　策】「何を確認したいのか」と「具体的にどの値が正解か」を区別すること

③期待値に複数のことが書いてある
例1）未入力の場合エラーになること、また、エラーメッセージが正しいこと
例2）[戻る]ボタンでメニューに戻り、[確認]ボタンで確認画面に遷移すること
【原　因】洗い出した機能・観点が整理されていない
【リスク】OKとNGが混在して状況が把握できなくなる（「一部OK」のように曖昧になる）
【対　策】条件と期待値が1対1になるまで細分化すること

 

後々のために書いておきたいこと


できれば右端の「設計根拠」の欄に、テストで確認すべき事項が設計書のどこに書いてあるかを書いておきたいものです。設計書に書いてあることとテストで確認することの対応を明確にすることによって、テストの抜け漏れ誤りを防ぐとともに、トレーサビリティーの確保に役立ちます。

次回（第４回）はデシジョンテーブルの作り方及びパターン番号、パターン説明の書き方を説明します。ご期待ください。
なお、検証サービスに対するお問い合わせは＜お問い合わせフォーム＞までお願いいたします。
ご愛読、ありがとうございました。

この連載のバックナンバー
(第１回)テスト設計の手順とセオリー
(第２回)テスト条件一覧（機能と観点の掛け算）
(第３回)テスト条件一覧（確認項目と期待値）
(第４回)デシジョンテーブル（曖昧さ排除テク）
(第５回)デシジョンテーブル（条件網羅テク）
(第６回)結合テストをどう考えるか
(最終回)結合テストの勘所