金融系のシステムの開発・テスト・保守を担当しています。その中で、Playwright（Node.js）を使ってE2Eテストの自動化スイートを作りました。約100画面・500テストケースをカバーし、CI/CDパイプラインで定期実行しています。
結果だけ書くと「リリースごとに約20人日かかっていた手動の回帰テストがほぼゼロになった」という話になりますが、ここに至るまでにやったことを書いておきます。
まず、最初から100画面を狙わないことです。
自動化は、作っている途中は価値を生みません。全部できてから使おうとすると、完成前に優先度が下がって立ち消えになります。なので、毎回必ず通る主要な導線だけを先に自動化して、その時点でCIに乗せました。少ないケースでも、毎日勝手に回り続けていれば壊れたときにすぐ気づけます。
次に、壊れるテストを放置しないことです。
自動テストが使われなくなる最大の理由は、「どうせまた落ちてる」と思われることだと思っています。一度そうなると、本当の不具合も見過ごされます。待ち時間でごまかさずに要素の状態で待つ、テストデータを毎回作り直す、失敗時のスクリーンショットとトレースを残す。地味ですが、この辺りに一番手間をかけました。
そして、何を自動化しないかを決めることです。
手動の手順書をそのままコードに移すと、メンテナンスだけがふくらんでいきます。画面の細かい見た目の確認や、仕様がまだ固まっていない部分は、無理に自動化せず手で見ると決めました。自動化するのは、壊れていたら困るもの、かつ仕様が安定しているもの。この線引きをしたことで、続けられる規模に収まりました。
実際に変わったのは、工数だけではありませんでした。
手動のころは、時間がないと「今回は影響範囲だけ見よう」となり、その判断自体がリスクになっていました。いまはリリースのたびにフルで回せるので、「見ていないところ」がある前提で話をしなくてよくなりました。自動化の価値は、浮いた時間よりもこちらだと思っています。
現在は、本業で統合テストのテスト設計レビュー（観点の妥当性の確認と、指摘のフィードバック）も担当しています。自動化は手段なので、そもそも何を確認すべきかが整理されていないと、コードにしても効きません。
これから自動化を始める方には、「小さく始めて、早くCIに乗せて、壊れたら直す」をおすすめします。自動化は作って終わりではなく、回し続けて初めて価値が出るものだと思っています。
