設計者ごとに異なるテストケースを作成していて、記載粒度が異なっていたり、テスト対象機能やテスト条件に抜け漏れがあったりする――。システム開発現場でよくある困った光景だ。
例えば、Webシステムの結合テスト工程において、チームリーダーのAさん、メンバーのBさん、Cさんの3人でテスト設計をしたとする。“駄目なテスト”になっている現場では、次のようなテストケースが作成される。
この3つのテストケースは、同じフォーマットを使用しているのに各項目の記述内容が異なっている。テストケースの「分類1」でAさんは「登録ボタン」、Bさんは「入力項目」と異なる画面のパーツを指している。Cさんは「データ登録」と操作内容を示している。分類2や分類3も同様で、3人でバラバラの言葉を書いている。
しかし、読んでみると、どれも入力フォームに金額の値を入力して、登録ボタンを押した場合の挙動を確認させようとしている。これだけ表記のばらつきがあると、テスト実行者が混乱してしまうだろう。
さらに、期待結果（テストケースの「期待値」）の記載粒度が異なっていることも分かる。
Aさんはエラーチェック処理ごとに、エラーメッセージの出力が設計通りに実装されているかどうかを確認しようとしている。Bさんは、エラーチェック処理の入力データの境界値（振る舞いが変わる境目）を網羅しようとしている。Cさんは期待値を「正常に処理されること」としている。エラーチェック処理の確認をしているのか、データベースへの登録の確認をしているのか、テスト設計書だけでは分からない。
これは、テストで検証しようとしている要素やイベントである「テスト条件」が異なる、ということだ。テストケースごとにテスト条件が異なるというのは、テスト範囲やテスト条件の網羅ができていないのと同義で、不具合摘出が不十分なままテストが終わってしまうおそれがある。
