E2Eテストは必要だとわかっていても、遅い、壊れやすい、保守しづらいで手が止まりやすい。
そのままだと、重要シナリオを守るはずの自動テストが、むしろチームの負債になっていきます。
E2Eテストを重荷ではなく、継続的に使える品質の土台へ変えやすかったのがこの本でした。
こういうチームに向いている
- すでにE2Eテストはあるが、失敗時の調査コストが高い
- テックリードとして、フロントエンドの品質保証を整理したい
- CIでE2Eを回したいが、どこから最適化すべきか迷っている
- Playwrightで書くべきテストと、ほかのテストへ任せる部分を切り分けたい
この本で持ち帰りやすいこと
- E2Eテストの役割を、ソフトウェアテスト全体の中で位置づけやすくなる
- Playwrightの機能を、便利さではなく保守性と実用性の観点で使いやすくなる
- テストコードの組み立て方や命名、再利用の考え方を持ちやすくなる
- 実戦投入時のリポジトリ配置、CI実行、プロジェクト管理とのつなぎ方が見えやすくなる
実務に引き寄せると良かった場面
- 新規導入時に、どのシナリオから自動化を始めるべきか考えやすかった
- レビュー時に、テストコードの可読性や壊れにくさを見る基準を持ちやすかった
- CI時間を短縮したい場面で、並列実行や実行対象の絞り方を考えやすかった
- フロントエンドとQAの会話で、E2Eとユニットテストの役割分担をすり合わせやすかった
- UIだけでなくAPIテストや応用的な使い方まで見えるので、Playwrightの使いどころを広げやすかった
さらに広げて読むなら
E2Eテストを品質保証全体の戦略へつなげたいなら、こちらをあわせて読むと整理しやすいです。
自動テストだけでは守れない品質まで見渡せる、フルスタックテスト戦略の入門書
まとめ
E2Eテストを重くて不安定な仕組みのままにしたくないなら、この本をもとに「壊れにくい書き方」と「CIで回る運用」をセットで見直してみてください。