結合テスト仕様書アンチパターン

結合テスト仕様書作成時・テスト時にやるべきことや、やるべきじゃないことを纏めてみました。

私の経験則なので主観がかなり入っておりますがご了承ください。

iPadなどの実機での動作やデザイン確認が必要である事が多くなっているので、実機のキッティング作業が必要な場合は決められたエンジニアだけに専任させる。
テスト仕様書はフォーマット化しておく。但し、デシジョンテーブルはなるべく使わない方向で表現する。
誰（第三者）が結合テスト仕様書を見ても同じテスト結果になるようなテスト仕様書にする。（要するにわかりやすくする）
スポットのテスターはブルックスの法則になりうるので、スポットのテスターはなるべく使わない。
事前データは必ず事前に用意しておく。可能ならテスター単位にDBインスタンスを用意し、お互いにデータが干渉されないようにしておく。それが無理なら最低限スキーマを分けておく。また、この作業は専任者がやる。
エビデンス取得ルールはテストフェーズ前にあらかじめ決めておく。あとからルール追加・変更はしない。
結合テストは必ずブラックボックステストにする。inとoutだけに着目するだけにする。
設計書は見ない。プログラムは見ない。結合テスト仕様書のみを見る。テストシナリオはOKかNGかだけである。

プロジェクトによって違いますけど、だいたいこんなもんかと思ったりします。