結合テスト仕様書アンチパターン
結合テスト仕様書作成時・テスト時にやるべきことや、やるべきじゃないことを纏めてみました。
私の経験則なので主観がかなり入っておりますがご了承ください。
- iPadなどの実機での動作やデザイン確認が必要である事が多くなっているので、実機のキッティング作業が必要な場合は決められたエンジニアだけに専任させる。
- テスト仕様書はフォーマット化しておく。但し、デシジョンテーブルはなるべく使わない方向で表現する。
- 誰（第三者）が結合テスト仕様書を見ても同じテスト結果になるようなテスト仕様書にする。（要するにわかりやすくする）
- スポットのテスターはブルックスの法則になりうるので、スポットのテスターはなるべく使わない。
- 事前データは必ず事前に用意しておく。可能ならテスター単位にDBインスタンスを用意し、お互いにデータが干渉されないようにしておく。それが無理なら最低限スキーマを分けておく。また、この作業は専任者がやる。
- エビデンス取得ルールはテストフェーズ前にあらかじめ決めておく。あとからルール追加・変更はしない。
- 結合テストは必ずブラックボックステストにする。inとoutだけに着目するだけにする。
- 設計書は見ない。プログラムは見ない。結合テスト仕様書のみを見る。テストシナリオはOKかNGかだけである。
プロジェクトによって違いますけど、だいたいこんなもんかと思ったりします。
| ☆彡 | デスマーチあるある |
|---|---|
| 責任 | 責任の所在なんて不明 |
| 指揮命令系統 | 上から下ではなく、超絶に複雑 |
| 肉体的ダメージ | ひどい |
| 精神的ダメージ | 超ひどい |
| 自己への学び | ITドカタであることを自覚できる |
| 退職者 | 多数 |
| 行方不明者 | 多数 |
| 時々 | トイレで人が倒れていた事 |
了
KHI入社して退社。今はCONFRAGEで正社員です。関西で140-170/80～120万から受け付けております^^
得意技はJS(ES6),Java,AWSの大体のリソースです
コメントはやさしくお願いいたします^^
座右の銘は、「狭き門より入れ」「願わくは、我に七難八苦を与えたまえ」です^^
コメント