テスト自動化失敗談を共有しよう！ by T-DASH Advent Calendar 2022の４日目の記事となります。
まとめ
- テスト自動化を検討する際にツールありきで考えてしまい、実際の開発プロセスに当てはめる際に受け入れてもらえなかった
- 「どのような開発プロセスの」、「どのフェーズに対して」、「何を確認するためのテストを自動化したいのか」を明確にする必要がある
失敗談
会社としてテスト自動化を推し進めるということで、新たにテスト自動化検討チームが立ち上げることとなり、私はそのメンバーの一人になりました。
その際に、
「単体試験ツールは既にそれぞれの開発プロジェクトで実施しているから良しとして、APIテストとE2Eテストは色々なツールがあるから、各ツールを調査して○×表作って選出しよう」
みたいな話になりました。
しかし、この進め方は大きく間違っていました・・・
何が間違っていたのか
現在の我々の会社は基本的にはウォーターフォール開発であり、いわゆる単体・結合・総合・システム試験が存在するような開発プロセスでした。（早くリリースするために一部テストを軽くしたりもしていますが）
単体試験は既にツールを使って運用していたので問題ありませんが、結合・総合・システム試験では使っておらず、基本的には人の手で実施したものが成果物（エクセル）となっています。
なので、自動テストツールから出力される成果物がこれまでの成果物と何が違うのか、それで十分なのか、を評価して関係者と合意しなければいけません。
結果
結果として、「APIテストとE2Eテストのツールからこれとこれが良いです」というものはあげたものの、「それは開発プロセスにどう当てはめるの？」となり、結局現状のプロセスの見直しまで後戻り作業が行われました・・・
当時はアジャイル開発にしていきたいとかそういう話も一緒に上がっていたので、カオスになっていたというのもありますが、それでももっとやりようがあったと思います。
教訓
まとめにも書いたとおり、テスト自動化を進めるにあたり、「どのような開発プロセスの」、「どのフェーズに対して」、「何を確認するためのテストを自動化したいのか」を明確にしてから具体的なツールの話をすべきだと思います。
また、結局やりたいことは「現状よりも工数を少なくして、早くリリースしたい」ということなので、テスト自動化に取り組むというよりは、現状の開発プロセス全体のボトルネックを調査して改善を検討するのが一番大事かと思いました。
あとこれは少し話が変わりますが、テスト自動化はチーム全体として必要だ、という認識を持って実施しないと続かないとも思っております（そうしないと結局メンテで苦労するので・・・）