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

求人

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

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

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

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

☆彡 デスマーチあるある
責任 責任の所在なんて不明
指揮命令系統 上から下ではなく、超絶に複雑
肉体的ダメージ ひどい
精神的ダメージ 超ひどい
自己への学び ITドカタであることを自覚できる
退職者 多数
行方不明者 多数
時々 トイレで人が倒れていた事

関西で140-170/80~120万から受け付けております^^
得意技はJS(ES6),Java,AWSの大体のリソースです
Python3.6,Djangoを勉強中です,Javaは少し飽きてしまってます–;
コメントはやさしくお願いいたします^^
座右の銘は、「狭き門より入れ」「願わくは、我に七難八苦を与えたまえ」です^^

スポンサーリンク
  • このエントリーをはてなブックマークに追加
スポンサーリンク

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA