単体テスト、結合テストで発生した障害の分析(どんな障害が起こって、原因はなんで、再発防止に関してどうすべきか)なんかをやってます。
個人的に各フェーズで留意する点などを。
共通
テスト云々の前に各フェーズで共通にやっておくべきこととして、以下
- テストデータ、ケースの適切な共有(日々変わってくるのでどのように共有しておくか。見やすさや視覚性を考えるとやはりExcelがベスト？)
- 上記を重要なプロジェクトとして認識しているか(フェーズの始まりぐらいになってようやく慌てて作るパターンが多いので最重要タスクとして認識できていることがポイント。)
- データの初期化、実行、検証プロセスを細かく回せる仕組みを準備しておく(実際の検証コストを最小限に抑える。自動テストがあればベスト。また実環境では毎回初期化は流石にできないため、投入データをdeleteするスクリプトまで書いておくと良い。)
- DI的にローカルで検証できるパターンを用意しておく。APIなど外部環境が絡むケースではローカルで検証できず、修正コストがやたらかかってしまう。
がやはり最重要かなと思っております。
単体テスト
いわゆる単機能に対するテストですね。
起こりやすい障害、トラブル
- 単純なコーディングミス
- ドキュメントの記載ミス、誤記
- 製造担当者の仕様の不理解(設計担当者の仕様の伝達が下手)
対策
- (身も蓋もないですが)単体テスト前にある程度の動作確認をしておく
- 仕様が複雑な部分に関するテストパターンの用意(パターンが多いケースに関しての自動化はすべし。特にバリデーション系など。)
- 異常系発生用のプログラムを書く、あるいはその手順を明確にしておく(DBのリネーム処理など)
- 目視で落ちやすいエラーに関してはある程度、機械的なチェックを考えておく(自動化ツールなど)
- パターンが多いもの、効率化できるものに対しては自動化を行う
結合テスト
起こりやすい障害
- データ量が想定と違い、いきなり画面が動かない、めちゃくちゃ重い
- 仕様認識齟齬(思ってたのと違う、ユーザーから仕様を吸い上げきれていなかった、チームごとの連携不足)
- 環境不備(特定環境で動かない)
対策
- 単体テストデータ作成時に桁ぐらいは確認しておく(それによりコーディングが変わってくる)
- テストデータを各チームで合同で作る(あるいは上位のベンダーがやりとりを行う)
- 環境情報はなるべくコード化しておき、差異がでないようにする(仮想環境構築ツールを使う。)
