再帰テスト・回帰テストの自動化(Automated Testing for Regression Test)

回帰テストの自動化の自動化の需要は多い、自動化の相談を受けると半分くらいは回帰テストについてかもしれない。しかし安易に回帰テストの自動化を行うのは考えものだ。なぜなら自動化で一番避けるべきメンテナンスコストの増加リスクがある。筆者も自分のプロジェクトで回帰テストの自動化をやったことはあるが、初回は大ゴケした(自動化スクリプトを全部捨てざるおえなかった)。なぜ失敗したかというとキャプチャーリプレイを多用して、自分でコードを書かなかったからだ。回帰テストのテスト範囲(ソフトウェアのコンポーネントの特定)は基本的に全部である。すべてのUIが関連する。ということは、どっかで常にUIが変更されているわけで、回帰テストケースセットは常に動かない状態になる。毎日UI変更に追従しなきゃならないから、新しいテストケースは追加されない。お金はかけるけど、200ケースを実行するのが限界みたいなる。残念ながら回帰テストは一番自動化テストのハードルが高く、最後に取り組む領域だ。別な言い方をすればパフォーマンステストを自動化するほうが100倍楽である。でもお客さんが「回帰テストの自動化したい!」と言われると、商売なので「そうですね。。。」とまず否定しない自分を心苦しく思ってる。。。それでも回帰テストを自動化しなきゃならない場合は以下の点を注意すべきだ

  • キーワード駆動型テストは必須である、絶対にキャプチャーリプレイは使ってはいけない
  • テストケースを見て、そのテストがホワイトボックステストやAPIテストで代替できるのなら、自動テストツールでの回帰テストを部分的にあきらめる

キーワード駆動形テストは説明の必要はないであろうが、ホワイトボックス・APIテストの代替は多少説明が必要かもしれない。先に述べたように