本記事は2024年に社内向けに発表した資料に加筆修正したものです。
目次
1. TL;DR（この記事の要点）
1.1. 主張
E2Eテストを効果的に導入することで、バグ発生率7.79%減少、QAコスト103MD削減、コードカバレッジ73.1% を達成した。成功の鍵は「選定→実装→計測」のサイクルを回し、優先順位の高いテストケースから自動化を進めたことにある。
1.2. 課題：質とスピードの両立（プロフィットツリー）
開発チームとして「質の高い製品を素早く届ける」ためには、品質とスピードの両立が必要である。以下のプロフィットツリーで、目標達成のために改善すべき要素を分解した。
E2Eテスト自動化による改善効果：
| 改善項目 | 施策 | 成果 |
|---|---|---|
| テスト漏れを減らす | 継続的な自動テスト実行 | バグ発生率 7.79%減少 |
| バグの早期発見 | CI/CDパイプライン統合 | 開発中にバグ検出 |
| 手動テスト工数を減らす | テストケースの自動化 | 103MD削減 |
| 手戻りを減らす | 早期発見による修正 | 修正コスト削減 |
1.3. 目指した指標
| 指標 | 目的 | 達成値 |
|---|---|---|
| バグ発生率 | 品質向上 | 7.79%減少 |
| QAコスト | 効率化 | 103.05 MD削減 |
| コードカバレッジ | 網羅性 | 73.1% |
1.4. 解決ワークフロー
以下の3ステップを継続的に回すことで、効果的なテスト自動化を実現した。
| ステップ | 内容 | ポイント |
|---|---|---|
| 選定 | バグ発生率の高いテストケースを特定 | QAチームとの協議で優先順位決定 |
| 実装 | Cypressでテスト実装、CI/CDに統合 | 継続的なメンテナンス |
| 計測 | カバレッジ・効果を検証 | データ品質の担保が重要 |
2. テストについてのおさらい
2.1. マイク・コーンのテストピラミッド（改訂版）
テストをその対象で分ける代わりに、テストの範囲によって分けることを提案する。ソフトウェアの中でテストが占める割合が大きいほど、ピラミッドの上部に配置される。
Figure 1.1. A revised version of the original test pyramid
2.2. 各テストの性質
2.3. ユニットテストの範囲
ソフトウェアの最も原子的な構成要素である関数を検証する。
ユニットテストはピラミッドの一番下にあるので、そのスコープは小さい。上に行くにつれて、テストがカバーする範囲が広がっていく。
2.4. 統合テストの範囲
統合テストは、ソフトウェアのさまざまな部分がどのように連携して動作するかを検証する。
統合テストのスコープは、単体テストのスコープよりも広い。統合テストは、関数がどのように相互作用するか、そして、ソフトウェアがどのようにサードパーティと統合されるかをチェックする。
2.5. E2Eテストの範囲
エンドツーエンドのテストは、ユーザの視点からアプリケーションを検証する。
End-to-endテストは外部の視点からソフトウェアとのインターフェイスを提供する。高度に分離されたアプローチをとることで、アプリケーションの広い領域をカバーする。
2.5.1. インターフェイスを検査対象により分類する
ウェブアプリケーションにおけるユーザの視点からのインターフェイスをテストの検査対象で分類すると以下のようになる。
アプリケーション全体
- GUI
- HTTP API
- WebSocket
- その他のリアルタイム通信技術などに依存する
バックエンド
- HTTP API
- WebSocket
- Webhooks
- RSSフィードやAtomフィード
- CLI
- EメールやSMS
- ...
2.5.2. E2Eテストの細分化
マイク・コーンのテストピラミッドからエンドツーエンドテストの領域を細分化し、HTTP APIテストをGUIテストの下に配置する。
HTTP APIテストの特徴:
- アプリケーションの広い範囲をカバー
- GUIテストの複雑さを伴わない
- 統合テストやユニットテストより遅い
- GUIを含むE2Eテストよりはるかに速い
- 強力な保証を提供
2.5.3. HTTP APIテストの範囲
HTTP APIテストは、アプリケーションのバックエンド全体と、アプリケーションが公開するHTTP APIをカバーする。
2.5.4. GUIテストの範囲
GUIテストはアプリケーションのすべての部分をカバーするため、テストピラミッドの中で最も高い位置にある。
GUIテストの特徴:
- アプリケーション全体の表面をカバー
- GUIに密結合だが、コードには密結合しない
- 最も遅いテスト
- 最も強力な保証を提供
GUIテストはアプリケーション全体を対象とする。クライアントを使用してバックエンドと対話するため、スタックのすべての部分にアクセスする。
2.6. アジャイルテストの4象限
縦軸がビジネス面と技術面、横軸がチームを支援する側面と製品を批評する側面。
出典: 『実践アジャイルテスト』P96
テストピラミッドに分類される自動テストの対象範囲は一般的にQ1〜Q2の領域に配置される。
2.7. テストケースの選定
表に色付けし優先順位を付けて並び替える作業をすることで特に自動化コストが低く、リスクや手動テストのコストが高いところから自動化する。
3. 成果報告
3.1. 当社にて現在本番稼働しているサービスにおける達成項目
| 指標 | 数値 | 説明 |
|---|---|---|
| バグ発生率減少 | 7.79% | 全テストケースにおけるE2Eテスト導入前と現在のバグ発生率の差 |
| QAコスト減少 | 103.05 MD | E2Eテストによって代替できた項目消化工数 |
| コードカバレッジ | 73.1% | E2Eテストによるラインカバレッジの網羅率 |
3.2. バグ発生率減少の要因
効果的なテストケースの選定
優先順位をつけてバグ発生率の減少効果が高いところから自動化を進めた。
3.2.1. プロセス
- Jiraのバグチケットからバグ発生率の高いテストケースを見つける
- 試験項目表と照合
- Cypress Dashboardで自動テストを実装して継続的に監視
QA項目の自動化する優先順位の付け方はQAチームと協議して決定した。
3.3. QAコスト減少の要因
継続的なテストのメンテナンス
CI/CDパイプラインにE2Eテストを統合し、継続的にテストコードのメンテナンスを行った。
E2Eテストによって代替できた項目消化工数 = 103.05 MD
- QAが手動で実施した場合のコスト: 0.025 MD/CASE
- E2Eが今まで実行したCASE数: 4122
- 0.025 × 4122 = 103.05 MD
3.4. コードカバレッジを効果的に高くできた要因
E2Eテストの特性
テストケース数ベースで自動化の割合を考えると：
約16.6%の自動化で73.1%のコードカバレッジを達成している。
これはテストピラミッドが示すように、E2Eテストが少ないテストケースで広範囲をカバーできる特性による。
3.5. コードカバレッジの水準
テストカバレッジ70%程度がどのくらいの水準かユニットテストの場合を見てみると：
思慮深くテストを実施すれば、テストカバレッジはおそらく80%台後半か90%台になるだろう。100%は信用ならない。
3.6. 選定、実装、計測のサイクルが重要
QAコストを効果的に減少させるためにはテストの選定、実装、計測のサイクルが重要。
3.7. テストの選定・実装についての考察
今回の経験を振り返りE2Eテストを更に整理してみる。
| QAコスト大、実装コスト大（少量） | QAコスト小、実装コスト小（大量） |
|---|---|
| シナリオを再現するための前提条件が多い | シナリオを再現するための前提条件が少ない |
| 依存するAPIエンドポイントが比較的多い | 依存するAPIエンドポイントが比較的少ない |
| 実装詳細に関わるので開発者がカバーするのが効果的 | 今後AIベースの自動テストツールの発展でカバーできるかもしれない（Autify, mabl, Testim等） |
3.7.1. E2Eテストのケース数ベースでの割合は20%ぐらいが上限
- ほとんどのバグはソースコードの10%〜20%から出るという考え
- 「アイスクリームコーン」というアンチパターンを避ける
単体テストを入れていく、そしてどこからやるかの話は『ソフトウェア品質を高める開発者テスト』にて紹介されている。複雑度やHotspot値によってスコア付けをし、特に複雑度が高いものはファイルを分割して複雑度を減らしてから単体テストを書く方法が紹介されている。
選定の振り返りに自動化割合とラインカバレッジを合わせて確認すると効果的？
3.8. テストの計測についての考察
誤った意思決定を防ぐためにもデータ品質は重要。当初、テストカバレッジの算出にbackendから自動生成されていたapi clientのコードも含まれていたので、正しい数値が算出できていなかった。
3.9. 成果報告の総括
「バグ発生率7.79%減少」「QAコスト103MD削減」「コードカバレッジ73.1%」という数値そのものではなく、これらの数値を導き出すに至ったプロセスにこそ、本取り組みの本質的な価値がある。
本報告では、QAチームとの協議を経て優先順位を明確に定め、バグ発生率の高いテストケースから着手している。これは「選定→実装→計測」のサイクルを回すという、地道ではあるが確実な方法論である。
成功の本質は数値ではなく、「なぜそのテストを書くのか」「何を計測すべきか」を常に問い続ける姿勢にある。
4. Next Actions
4.1. 効果的なテストケース選定プロセスの探索
- バグ発生率の説明変数を見つける
- 実装工数、コードの複雑度、...
テストデータの更なる収集が必要:
- メタデータをテストコードに与えていく
- テスト失敗の原因データを集める
参考:
- 品質とスピードに関する16の質問に答えてみた - t_wada（和田 卓人）
- E2Eテストのテスト結果を可視化することで気づきが生まれた | メルカリエンジニアリング