指標ドリブンで E2E テストを改善！実行時間半減・成功率 99%を達成するまで

指標ドリブンで E2E テストを改善！実行時間半減・成功率 99%を達成するまで

はじめに

こんにちは！atama plusでQAエンジニアをやっている池上です。
この記事はatama plus Advent Calendar 2025の12月19日の記事です！

自動テストを導入したものの、「実行に時間がかかる」「テストがよく失敗する」といった課題に直面している方もいらっしゃるのではないでしょうか。
本記事では、E2Eテストの改善活動において「評価指標の設定」と「データに基づく改善サイクル」がいかに重要かを、実際の改善事例を通じてご紹介します。

テスト自動化を進めているQAエンジニアやソフトウェアエンジニアの方の参考になれば幸いです！

改善前の状況と課題

atama plusでは、本番リリース前に実施する最終的な品質確認テスト(以下、リリーステスト※atama plusではこのテストをリリーステストと呼んでいます)において、Playwrightを用いた E2Eテストを実施しています。
テストはCircleCI上でスケジュール実行しており、開発中には開発環境で手動実行も行っています。

対象となるテストケースは約750ケースで、プロダクトの成長に伴い機能数が増えていく中で、テストケース数も年々増加してきました。

CircleCI上での実行をリリーステスト運用に組み込んでからしばらく経ち、運用を振り返ってみたところ、以下のような課題が明らかになりました。

• 実行時間が70分前後と長い
  • リリース前の確認サイクルに時間がかかり、素早いフィードバックが得られない
• 全体成功率が95%前後
  • テストが失敗した際に、本当の不具合なのか、テストの問題(テストケースやテストデータ不備)なのか判断に迷う
  • 特にテストの失敗数が多く、切り分けが大変という声が多く上がっていました
  • 失敗したテストを再実行しながら切り分けを行っていたが、失敗数が多いことで切り分けに時間がかかり、他のリリーステスト作業を圧迫していた
• 評価指標がない
  • 実行時間70分は妥当なのか、短縮すべきなのか判断できない
  • 成功率95%を改善すべきなのか、他の課題を優先すべきなのか決められない
  • どの程度改善できているのか、何を目指すべきなのかが不明瞭
  • 指標がないことで改善の優先順位が決められず、改善サイクルを回せない

特に問題だったのは、評価指標が存在しないことでした。
「なんとなく改善したい」という感覚はあっても、具体的に何を目指すべきか、どこから手をつけるべきかが分からない状態でした。
この状況を打破するため、指標ドリブンでの改善活動を開始しました。

改善へのアプローチ

評価指標の設定

まず、E2Eテストが目指すべき姿を「信頼性」と「速度」の 2 軸で定義しました。

信頼性が低いと以下の問題が発生します。

• テストを実行しても意味がないと認識されてしまう
• 対処すべきプログラムの不具合を見逃す

速度が遅いと以下の問題が発生します。

• テスト実施のハードルが高くなり実行されない
• 検知〜不具合修正までのリードタイムが増加する

これらを踏まえ、以下の具体的な評価指標を設定しました。

指標	目標値
信頼性 ①： 1回の実行での成功率	98%以上
信頼性 ②： 個々のテストの直近10回での成功率	80%以上
速度： 全体実行時間	60分以内

目標値を設定した根拠

それぞれの目標値は、現状の課題と改善の実現可能性を考慮して設定しました。

• 1回の実行での成功率98%以上

  • 現状の95%では750ケース中約37ケースが失敗する計算になり、切り分け作業が大きな負担になっていました
  • 98%であれば失敗するのは約15ケースとなり、切り分け作業を半減できます
  • また、失敗が少ないことで「失敗=本当の不具合の可能性が高い」という信頼が生まれ、テスト結果をより重視できるようになります

• 個々のテストの直近10回での成功率80%以上

  • 全体として98%を達成しても、特定のテストが頻繁に失敗していると改善の余地があります
  • E2Eテストでは環境要因などにより不安定になることがあるため、ある程度の失敗は許容する必要があります
  • 80%(5回に1回の失敗)を下回るテストを「不安定なテスト」として可視化し、優先的に改善対象とします
  • この指標により、問題のあるテストを見逃さず継続的に改善できます

• 全体実行時間60分以内

  • CircleCI上でのスケジュール実行では人の手はかかりませんが、開発中の手動実行を考えると60分以内には抑えたいと考えました
  • また、現状70分から大幅な短縮は難しいと想定し、まずは実現可能性の高い「10分短縮」を目標としました
  • 1時間以内であれば、開発フローの中でテストを実行する心理的ハードルが下がり、より頻繁にテストを実行できるようになります

データ可視化基盤の構築

評価指標を継続的に追跡するため、以下の可視化基盤を構築しました。

データフロー

CircleCI → BigQuery → Looker Studio

CircleCI自体にもTest Insightsというテスト結果分析画面がありますが、分析したい内容に合わせてカスタマイズできないため、BigQueryとLooker Studioの組み合わせを選択しました。

ダッシュボードで可視化した指標

• 全体実行時間の推移(時系列グラフ)
• 全体成功率の推移(時系列グラフ)
• 直近10回で成功率80%未満のテスト一覧(テーブル)
  以下は実際のダッシュボードです。
  
  

改善サイクルの実行

月次で指標を確認し、要因分析を行い、改善施策を実行するサイクルを確立しました。
この振り返りは、QAチーム内のPlaywright管理者(3名)で実施しています。Playwright管理者は、Playwrightに関わる業務についてリードし、自動テストによるテストプロセスの課題解決や、Playwrightテストコード管理について責任を持つメンバーです。

月次の振り返りプロセス

1. 指標の確認: Looker Studioのダッシュボードで3つの指標をチェック
2. 要因分析: 目標未達の指標について、データを深掘りして原因を特定
   • ダッシュボードから問題のあるテストケースを特定
   • 実際に対象テストのコードを読んだり、実行してみたりして原因を地道に深掘り
   • 1人で分析するだけでなく、Playwright管理者で議論しながら進めることも
3. 施策の立案: 特定した原因に対する具体的な改善施策を検討
4. 優先順位付け: 効果とコストを考慮して実施する施策を決定
5. 実行と評価: 施策を実行し、次回の月次で効果を確認

改善施策を立案するにあたっては、以下の点に注意しています。

• 数字をハックする施策の立案はNG
  • 例えば、失敗するテストを削除するだけでは本質的な改善にならない
  • 実行時間が長いテストを除外するだけでは、テストカバレッジが下がる
  • 指標が良くなっても、テストの価値が下がる施策は避ける
• あくまでテストが目指す姿(信頼性と速度)となることを目指す
  • テストの価値を維持・向上させながら、指標を改善する

実施した具体的な改善施策

2ヶ月間で以下の3つの施策を実行しました。

施策 1: テスト観点の見直し

課題の発見
Playwright管理者でテストコード全体を読み合わせて確認していったところ、重複したテスト観点のケースが存在していることが分かりました。
atama plusでは教材を扱うプロダクトのため、多くの教科(数学・英語など)があります。教科によってはコンテンツが異なるだけで学習体験としては同じ教科があるということに着目しました。例えば、高校数学と中学数学は学習体験としては同じで、コンテンツが異なるのみです。

実施内容
同じ学習体験をカバーしている重複ケースを特定し、約5ケースを削除しました。1ケースあたり1〜2 分程度かかるため、この施策により約10分の実行時間削減に貢献しました。

施策 2: 失敗が多いケースの修正

課題の発見
Looker Studioのダッシュボードで「直近10回で成功率80%未満」のテストを特定したところ、テストデータの問題で失敗しやすいケースが複数存在していました。

原因の分析
ダッシュボードから問題のあるテストケースを特定し、実際にテストコードを読んだり実行したりして原因を深掘りしました。
Playwright管理者で議論しながら分析を進めた結果、以下のような問題が明らかになりました。

• テストアカウントの共有による影響
  • 同じテストアカウントを複数のテストで使用しており、あるテストの動作が他のテストに影響していた
    • 例: ある画面でフィルター絞り込みをすると絞り込みが保存されるが、他のケースでフィルター絞り込みの結果がうまく動かない
  • アカウントの同時ログインは許容していないが、同じアカウントを使いまわして並列実行していたため失敗してしまうケースがあった

実施内容
テストアカウントの使い分けやテストデータの整備を行い、テスト間の依存関係を解消しました。合計で約10ケースを修正し、全体成功率の向上に大きく貢献しました。

施策 3: テストケースの並列化

課題の発見
実行時間の内訳を分析していたところ、並列化の余地があることに気づきました。
もともとアプリごと(生徒アプリ、管理アプリなど)にジョブを分けて別々に実行できるようにしていましたが、各ジョブ内では1 workerでの逐次実行となっていました。
CircleCI導入当初は動作確認を優先していたため、並列度の最適化まで手が回っていなかったのです。
Playwrightには並列実行機能があり、worker数を指定して並列度を制御できます。
CircleCI のジョブ内で実行するPlaywrightのworker数を調整することで、大幅な実行時間短縮が見込めると考えました。

実施内容
ジョブごとにPlaywrightのworker数を調整できるよう設定を変更し、最適な並列度を探る試行錯誤を行いました。
並列度を変えながら、以下の観点を確認して調整しました。

• 実行時間: worker数を増やすことで期待通り短縮されているか
• テスト成功率: 並列度を上げることでテストが不安定になっていないか
• CircleCI の負荷: リソースを過度に消費していないか

この試行錯誤の結果、基本的に4 workerでの実行を採用し、一部負荷の高いジョブでは2 worker で実行するという設定に落ち着きました。
この最適化により、約30分の実行時間短縮につながりました。

改善の成果

定量的な成果

2 ヶ月間の改善活動により、以下の成果を達成しました。

指標	改善前	改善後	達成状況
実行時間	約 70 分	約 30 分	✅ 目標達成(60 分以内)
全体成功率	約 95%	99%維持	✅ 目標達成(98%以上)
個別テスト成功率	80%未満が複数存在	改善中	🚧 継続改善中

実行時間は半減し、成功率は 99%を安定して維持できるようになりました。
個別テストの成功率については、全体のテスト数 約750ケースのうち、約20件程度は不安定なテスト(成功率50%程度)が残っている状態です。こちらは引き続き改善を進めています。

定性的な効果

数値の改善だけでなく、チームやプロセスにも以下のような変化がありました。

• テスト結果への信頼度が向上

  • 失敗数が減ったことで、「失敗=本当の不具合の可能性が高い」という認識が生まれた
  • 実際に作業を担当するメンバーからは「失敗数が減り、心理的負担含めて作業がやりやすくなった！」という声をもらいました

• 切り分け作業の大幅な削減

  • 現在は失敗数が数件となり、切り分け含めて数十分で完了できるようになった
  • その分、他のリリーステスト作業に集中できるため、リリーステスト全体の完了が早くなった

• 改善の優先順位付けが明確に

  • 指標があることで、「何を改善すべきか」が客観的に判断できるようになった
  • データに基づいた意思決定ができるようになり、改善活動の方向性に迷わなくなった

• 継続的な改善文化の醸成

  • 月次の振り返りサイクルが定着し、継続的に改善を回せるようになった
  • 指標の可視化により、改善の成果を実感しやすくなった

苦労したこと・学んだこと

改善活動を進める中で、いくつかの困難に直面しましたが、それらを乗り越える過程で多くの学びがありました。

指標設定の難しさ

他社事例も調査してみたものの、プロダクト特性によるところは大きく、具体的にどの値に設定するかはよりどころがなく苦労しました。
最終的には、もともとの実行時間や成功率から「どれくらい改善できるとうれしいか?」という観点で目標値を決めました。
完璧な指標を最初から設定するのは難しいため、まずは仮説を立てて設定し、運用しながら調整していくアプローチが重要だと学びました。

チーム横断での協力体制

データ可視化基盤の構築にあたっては、QAエンジニアだけでは難しい部分がありました。

• CircleCIからBigQueryへのデータ転送: CircleCIの設定やBigQuery転送の仕組みに詳しいSREチームの協力を得て実装
• Looker Studioでのダッシュボード作成: データ構造の理解やクエリ作成についてデータエンジニアの協力を得て推進

改善活動を進めるには、他チームの協力が不可欠であることを実感しました。

試行錯誤の重要性

Playwright管理者でテストコードを調査し、「ここだ！」と思った原因に対して修正を入れたものの、変わらず失敗してしまうということもありました。
試行錯誤しながらではありましたが、泥臭く修正を続けることで、最終的に原因を特定できました。
一発で解決できることは稀で、粘り強く取り組むことが大切だと学びました。

改善を加速させる時間の使い方

こういった改善活動は、一気に進めてしまうのが大事だと考えました。
そこで、週に1時間必ず時間を確保(合宿という形)して、Playwright管理者で集中的に進めました。
定期的に集中する時間を作ることで、改善のモメンタムを維持でき、2ヶ月という短期間での成果につながったと感じています。

予想外の成果

実行時間に関しては60分を目標にしていましたが、現在は約30分となり、予想外に短縮できたのはうれしい誤算でした。
複数の施策を組み合わせることで、当初の想定を超える効果が得られることもあると実感しました。

今後の展望

今回の改善により、E2E テストの基盤は大きく強化されました。しかし、まだ取り組むべき課題は残っています。

Visual Regression TestのCircleCIへの組み込み

現在、Visual Regression Testはキャプチャー取得環境の都合(CircleCI上で取得すると WindowsやMacとは異なるOS)により、手動で実行しています。
さらなる効率化のため、CircleCIに組み込むことで、ビジュアル面も含めた包括的な自動テストを実現したいと考えています。

開発環境でのテスト実行の安定化

開発環境では、リリーステスト実行環境とテストデータやスペックが異なるため、テストを実行しても失敗してしまうケースが多く発生します。
また、CircleCIからの実行に対応していないため、手動実行するしかなく、端末負荷が高く他作業へ影響が出てしまいます。開発環境でも安定してテストを実行できる環境を整えることが次の課題です。

改善活動を続けていくために

今回の改善を通じて実感したのは、リグレッションテストを安定して実行できる環境を整えることの重要性です。テストが安定していれば、開発プロセスの中で安心してリグレッションテストを実行でき、結果として品質の高いプロダクト開発につながります。

開発を取り巻く環境は日々変化していて、特に生成AIの登場で開発スピードもどんどん上がっています。その中で、自動テストの重要性はむしろ増していくと感じています。

引き続き、新しい技術や手法も取り入れながら、atama plusのQAチームとしてE2Eテストの改善を続けていきたいと思います。

最後に

本記事では、E2Eテストの改善において評価指標を設定し、データに基づいて改善サイクルを回した取り組みをご紹介しました。

改善のポイント

• 「信頼性」と「速度」という 2 軸で評価指標を設定する
• データ可視化基盤を構築し、継続的に追跡する
• 数字をハックせず、本質的な価値向上を目指す
• 月次で振り返り、改善施策を実行する

このアプローチにより、2ヶ月で実行時間を半減させ、成功率99%を達成することができました。

指標設定が改善の第一歩

自動テストを導入しても、「実行時間が長い」「よく失敗する」といった課題に直面することは多いのではないでしょうか。私たちもまさにそうでした。

そんなときに効果的だったのが、自社プロダクトに合った指標を設定して改善サイクルを回すことでした。
指標があることで「今どこに問題があるのか」「何を優先すべきか」が見えるようになり、チームで同じ方向を向いて改善を進められました。

最初から完璧な指標を設定できたわけではありません。
他社事例を調べても、結局プロダクトごとに状況は違います。
「どれくらい改善できたらうれしいか？」という素朴な問いから目標を決め、運用しながら調整していきました。

また、改善活動は一人で抱え込まず、チームで進めることが大事だと感じました。
週次で「合宿」として時間を確保し、Playwright管理者で集中的に取り組んだことで、モメンタムを保ちながら進められました。

自動テストの改善は地道な作業の連続ですが、指標を持つことで着実に前に進めます。
この記事が、同じような課題に取り組んでいる方の参考になればうれしいです！