7ヶ月でE2Eテスト3.6倍！本番不具合25%減を実現したQA活動の記録

こんにちは、プロダクト開発本部 QA チームのNです。

今回は、E2E テスト自動化ツール「Autify」を用いて行った、E2Eの自動テストを爆増させた品質改善活動について共有します。
この取り組みの結果、以下の成果を達成しています！

本番環境での不具合検知数：月平均で 25%削減
リリース前の E2E テストによる不具合発見数：月平均で 22 倍に増加

同様の課題をお持ちのチームにとって、具体的な改善点の参考になれば幸いです。

1. 背景
2. 目標
3. アプローチ
- 3-1. テスト方針の策定
- 3-2. 具体的な改善テクニック
4. 結果
5. まとめ

1. 背景

2024 年末当時、リリース前に検知しきれなかった不具合が、本番環境で不具合として検知されるケースが続いていました。

▼ チケット化された不具合の例
特定の条件下で申請操作をすると、エラーが発生する
データ連携時の自動計算が、正しく保存されない
通知機能で、意図しない表示崩れが発生する

これらはユーザーの業務に直接影響するため、リグレッションテストの網羅性を高めることが課題でした。

2. 目標

そして、上記の課題に基づき、2025 年上半期のQAチームの目標として以下を設定しました。

1. 定量的目標: 本番で検知される不具合を、月平均 7 件以下に抑制する
2. 定性的目標: 主要 4 機能（チケット・WF・経路・組織図）の E2E テストを網羅する

この目標を達成するため、Autify のテストシナリオを拡充することとなりました。

3. アプローチ

3-1. テスト方針の策定

テスト自動化を進めるにあたり、まず最初に取り組んだのがテスト仕様書の作成です。
これは、「全網羅とは何か？」という疑問に答えるため、すべての機能を洗い出して網羅性を可視化するために作成しました。
そして以下の2つの方針を定めました。

テストケースの優先順位づけ 不具合発生頻度からテストケースの優先度を「高・中・低」で定義しました。主要4機能における優先度「高」のテストから着手し、最終的には網羅性担保のため「低」のテストまで実装を広げました。
テストシナリオの一貫性 「ボタンが押せるか」といった断片的な確認ではなく、「申請から承認まで」のように、ユーザーの一連の操作を保証するシナリオを基本としました。この方針により、チームメンバー全員が同じ認識で、一貫性のある高品質なテストシナリオを構築することができました。

3-2. 具体的な改善テクニック

次に、テスト作成の生産性を上げるために工夫した、8 つのテクニックをご紹介します。

テスト設計

1. シナリオの部品化（ステップグループの活用）
課題：ログインやデータ準備といった共通の処理を毎回作成する手間が増え、メンテナンスが大変になる
対応：共通する操作を「ステップグループ」として部品化し、一つの変更が複数のシナリオに自動で反映されるようになりました

2. シナリオの整理（ラベル管理）
課題：増え続けるシナリオの管理が煩雑になる
対応：テストの目的や影響範囲を明確にするため、「ラベル管理」を導入しました。これにより、目的のテストを素早く見つけ出せるようになりました

自動テスト実装

1. AI によるセレクタ自動生成の活用
課題：UI 変更によるセレクタ破損とメンテナンスコスト
対応：Difyによるセレクタ生成アプリを活用し、UI変更に強い汎用的なセレクタを使用することで保守性の高いテストを実装しました

2. JS スニペットの活用
課題：高度なテスト作成の属人化
対応：Difyによるコード生成アプリを活用し、60 種類以上の JS スニペットをチームで共有しました

▼ 作成したスニペット例

スニペット名	これで何ができる？
`REST APIでチケットを作成する`	テストの準備を1STEPで終わらせる
`本日の日付をYYYY-MM-DD形式で取得する`	変動する日付のテストを自動でできるようにする
`ワークフロー名を指定してチケットを全件アーカイブする`	テストで増えたデータをクリーンな状態にする
`テキストの内容で要素を探してクリックする`	IDが変わるボタンも、文字で探して確実にクリックする
`ランダムなメールアドレスを生成する`	毎回違うメールアドレスが必要なテストの実行ができる
`スナックバー（トースト通知）の文言を検証する`	画面に出てすぐ消える通知を確実にチェックする

▼ スナックバー検証のコード例
非同期で表示されるトースト通知を確実に検証するためのJSステップの例です

// スナックバー（トースト通知）の文言を検証
const TIMEOUT_MS = 8000;  // 最大待機時間
const INTERVAL_MS = 100;  // ポーリング間隔
const TARGET_TEXT = targetText;  // 期待する文言（変数で渡す）

function getLatestSnackbar() {
  // 最新のスナックバー要素を取得
  // セレクターは環境に応じて変更してください
  const elements = document.querySelectorAll('[YOUR_SNACKBAR_SELECTOR]');
  return elements[elements.length - 1] || null;
}

return new Promise((resolve, reject) => {
  const startTime = Date.now();

  function checkSnackbar() {
    try {
      const snackbar = getLatestSnackbar();

      if (snackbar) {
        const actualText = snackbar.textContent.trim();
        if (actualText === TARGET_TEXT.trim()) {
          return resolve(true);  // 文言が一致
        } else {
          return reject(new Error(
            `文言が不一致: 期待="${TARGET_TEXT}" 実際="${actualText}"`
          ));
        }
      }

      // タイムアウトチェック
      if (Date.now() - startTime >= TIMEOUT_MS) {
        return reject(new Error('スナックバーが表示されませんでした'));
      }

      // 次のポーリング
      setTimeout(checkSnackbar, INTERVAL_MS);
    } catch (error) {
      reject(error);
    }
  }

  checkSnackbar();
});

このスニペットをAutifyのJSステップとして登録することで、非同期UIの検証が簡単に行えるようになります。

実行環境の安定

1. データ準備の API 化
課題：UI 操作によるテストデータ準備の長時間化と不安定さ
対応：REST API経由でのデータ準備に切り替え、高速化・安定化を図りました

この取り組みの具体的な実装方法やコード例については、以下の記事で詳しく解説しています。ご興味のある方は、ぜひご覧ください！
tech.kickflow.co.jp

2. ログイン時のリダイレクト対応
課題：ログイン後に複数回リダイレクトが発生し、テストが不安定になる
対応：ログイン処理をステップグループとして部品化し、JavaScriptでログイン前のURLを取得するようにしました。ログイン後に元のURLへ正しく遷移するように制御することで、不安定なリダイレクトによるテストの失敗を防ぎました。

3. テストの独立性確保
課題：テスト間のデータ依存による連鎖的な失敗
対応：クリーンアップステップを活用し、各テストを分離しました

4. シナリオの並列実行
課題：直列実行によるテスト時間の長時間化
対応：ランダムなメールアドレスを生成するJSスニペットを活用し、テストごとにユニークなメールアドレスを使用することで、メール通知を伴うテストも並列実行を可能にしました。これにより、実行時間を大幅に短縮しました（例: 2 時間 49 分 →11 分）

保守性向上

1. 柔軟なエラーハンドリング
課題：許容できる軽微な失敗によるテスト中断
対応：「エラーとして続行」設定を使い、一度に多くの問題を検知できるようにしました

2. Visual Regression の閾値調整
課題：レンダリングの僅かなズレによる不要な失敗通知
対応：閾値を 1〜2%に調整し、意味のある差分のみを検知対象としました

4. 結果

上記の結果、プロダクトの品質指標に改善が見られました。

4-1. 品質の変化

ユーザー報告による本番不具合は月平均 10.42 件から 7.86 件へ約 25%減少
自動テストがリリース前に発見した不具合は月平均 0.42 件から 9.29 件へと約 22 倍に増加

改めて集計してみると、これまでユーザーが遭遇していた可能性のある不具合の多くを、開発プロセスで検知できるようになったことがわかります。

発見元	2024 年 (月平均)	2025 年 (月平均)	変化
ユーザー報告不具合 (本番)	10.42 件	7.86 件	約 25% 減少 ↓
自動テスト発見不具合 (リリース前)	0.42 件	9.29 件	約 22 倍に増加 ↑

4-2. 直近の成果 (2025年6月〜7月)

テストシナリオの拡張が加速した6〜7月に絞ると、取り組みの成果がはっきりと現れています。

発見元	2025年6月	2025年7月	2024年 (月平均)との変化
ユーザー報告不具合 (本番)	4 件	3 件	約65%減少 ↓
自動テスト発見不具合 (リリース前)	23 件	31 件	約55倍に増加 ↑

4-2. 累計シナリオ数の推移

地道な活動の結果、テストシナリオ数を7ヶ月で85本から307本まで増やすことができました。

4-3. 自動テスト実装体制の構築

後半にテストシナリオの「爆増」を可能にしたのは、正社員と業務委託メンバーによる協業体制です。
シナリオがある程度増えてきたところで、後半の3ヶ月間は業務委託メンバーの育成に注力しました。具体的には、私たちが作成したテスト項目書をタスクチケットとして切り出し、これを彼らに割り当てていきました。

これには2つの効果があったと考えています。

属人化の防止: 正社員が都度指示を出すのではなく、テスト項目書というドキュメントを起点とすることで、誰でも同じ品質のテストシナリオを作成できる仕組みを構築しました。
レビューの効率化: メンバーには「実装完了後、必ずテストを実行して成功させてからレビューを依頼する」というルールを徹底しました。このルール化によって、単純な実装ミスの指摘を未然に防ぎ、レビューの負担を大幅に減らすことができました。

また、単にシナリオ数を増やすだけでなく、チーム全体に以下のようなメリットがありました。

テストシナリオ構築の加速: 正社員がテストの設計やレビューといったより高度な業務に集中できるようになったことで、シナリオ作成が大幅にスピードアップしました。
知見の共有とスキルアップ: 業務委託メンバーが自走できる仕組みを整えたことで、チーム全体のテスト自動化に関する知見が深まり、各メンバーのスキルアップにも繋がりました。