🤖
ただのエンジニア目線でE2Eテスト自動化についてまずはまとめてみた
この記事は、
・テスト自動化に興味はあるが、まだ導入経験がない人
・「とりあえず自動化しよう」と言われて不安な人
向けに書いています。
ご存じの方からすると釈迦に説法なのですが、一度原点に立ち返ってまとめてみましょう。
概要
そもそもE2Eテストとは...
End to End Testing
E2Eテスト＝ユーザー操作を起点に、画面から裏側まで全部つなげて確認するテスト
であり、
E2Eテスト＝「本番と同じ使い方」を機械にやらせるテスト
であり、
E2Eテスト＝最後に壊れてないかを保証するテスト, リリース前の保険
である。
モジュールが最もつながった状態で行うテスト、シナリオ等を用いて表示やふるまいの検証を行うテスト。
現場やPJによりけりだと思いますが、いわゆる「システムテスト」「シナリオテスト」を指します。
E2Eテストの自動化とは
ユーザーの操作を起点に、画面・API・DBまでを一連の流れで自動検証すること
（シナリオテスト、リグレッションテストの自動化）
- 代表ソフトウェア：
- Cypress
- Selenium
主なメリット
| 観点 | 効果 |
|---|---|
| 品質 | 人手では不可能な回帰テスト量 |
| スピード | リリース前の確認が数時間→数分 |
| 再現性 | 「あの時動いてた」が消える |
| 心理 | リリース恐怖が減る |
| 組織 | 属人化の排除 |
主なデメリット
| デメリット | 実態 |
|---|---|
| 初期コスト | ほぼ必ず想定超え |
| メンテ | UI変更＝即壊れる |
| 過信 | テストがある＝安全ではない |
| 運用 | 作った人が消えると死ぬ ➡逆に俗人化している |
案件適合性
フローチャート
うまくまとめられていない気がするけど、なんとか頭の中を絵にするとこんな感じ
収益性
E2Eテスト自動化の収益は、
「作った瞬間」ではなく「使い続けることで」発生します。
ここだけは、走りながら考えるのではなく、着手前にしっかりと煮詰める必要があると考えます。
- 人手テスト削減
- 障害・手戻り削減
- 安心してリリースできることによる開発スピード向上
良い循環
E2Eがある
↓
リリースが楽になる
↓
使われ続ける
↓
保守する価値が出る
↓
さらに安定する
具体例別
「ぜひやるべき案件」の実例
例①：既存BtoBシステム（長期運用）
- 5年以上運用予定
- 年10回以上リリース
- 毎回同じ業務フロー確認
判断：⭕ 絶対やるべき
- 初期費用：回収可能
- メンテ費用：毎回の人手削減で吸収できる
例②：パッケージ開発（複数顧客）
- 顧客が増えるほど確認工数増大
- 後方互換が重要
判断：⭕ 最優先でやるべき
- 1本のE2Eが複数顧客を守る
- メンテ費用 ＜ 障害対応コスト
例③：新規開発だが手順が異常に複雑
- 複雑な初期データ投入
- 組み合わせ爆発の入力チェック
判断：△ 手順単位で部分自動化
- 全E2Eは不要
- 人がミスりやすい手順だけ自動化
- 後にE2Eへ昇格可能
5. 「やらないべき案件」の実例
例④：短期MVP・PoC
- 3ヶ月で終了
- UIが毎週変わる
判断：❌ やらない
- 回収前に捨てることになる
- 手動＋軽いスクリプトで十分
例⑤：単発受託・ワンオフ
- 納品したら終了
- 保守契約なし
判断：❌ 基本NG
- E2Eは資産化されない
- メンテする人がいなくなる
**E2E自動化は「テストを作る話」ではない。
そのテストを“何回使うか”の話である。**
**E2E自動化は、正しく設計すれば利益を生む。
間違えれば、ただの高価な負債になる。**
個人的には、
「全部自動化する」ではなく
「壊れやすい部分は自動化しない」
という判断が一番大事だと思っています。
Discussion
僕個人の意見としては、案件適合性が高ければ積極的に自動化にTRYしていくべきです。