QAAIX
QAAIX

テスト自動化で挫折しないための3原則｜フレイキーテストを撲滅し保守性を勝ち取る

テスト自動化
よくあるお悩み
  • テスト自動化を導入したが、UI変更のたびにテストが壊れて修正工数が膨らんでいる
  • 毎朝CIのテスト結果がランダムに赤（失敗）になり、誰もテスト結果を信じなくなっている
  • カバレッジの数値目標に追われ、中身のない無駄なアサーションが増えている

なぜ多くのテスト自動化プロジェクトは「負債」化するのか

「リリース前の手動リグレッションテストをゼロにしたい」という意気込みで始まったテスト自動化プロジェクトが、半年後には**「CIが落ちても再実行ボタンを押してやり過ごすだけの形骸化した置物」**になってしまう光景を、私たちは何度も見てきました。

テスト自動化が破綻する最大の理由は、ツールの選定ミスではありません。「テストコードも本番コードと同じく保守コストが発生する資産である」という認識の欠如と、**「ピラミッド設計を無視したE2Eテスト偏重」**にあります。

画面のセレクタ変更で即座に壊れるテスト、タイミングの揺らぎで時々落ちるフレイキーテスト（Flaky Tests）が数本混ざるだけで、チーム全体の開発速度と自動テストへの信頼は瞬く間に失われます。

原則1：テストピラミッドを遵守し、E2Eテストは「価値の核心」に絞る

テスト自動化で最初に犯しがちな過ちが、すべてのシナリオをブラウザ経由のE2Eテストで担保しようとすることです。

E2Eテストは実行速度が遅く、環境起因のエラーを受けやすく、メンテナンスコストが最も高額です。

        ▲
       / \      E2E Tests (最上層: 最も薄く、ハッピーパス中心)
      /   \     - 決済完了、重要サインアップ導線など数本に厳選
     /-----\
    /       \   Integration / API Tests (中層: 堅牢かつ高速)
   /         \  - スキーマ検証、ビジネスロジック統合、DB境界
  /-----------\
 /             \ Unit Tests (基底層: 最も厚く、網羅的に実行)
/---------------\ - 純粋関数、ドメインロジック、エッジケース
  • ユニットテスト: ビジネスロジックの分岐やエッジケースは、高速かつミリ秒単位で完了するユニットテストで徹底的に網羅します。
  • API/結合テスト: 複数のモジュールやDBが絡む結合検証は、ブラウザUIを介さないAPIテスト層で担保します。
  • E2Eテスト: ユーザーにとっての最重要コンバージョン（会員登録、商品購入決済など）の正常系ハッピーパスのみに絞り込みます。

原則2：スリープ（sleep）を禁止し、状態待機と安定セレクタを徹底する

フレイキーテストの主犯は、非同期処理に対する「とりあえず sleep(3000)」と「脆弱なCSS/XPathセレクタ」です。

1. 固定秒数スリープの全廃

await page.waitForTimeout(3000) のようなハードコードされた待機は、CIマシンのスペック変動やネットワーク遅延で簡単に失敗します。必ず「特定のDOM要素が表示される」「特定のネットワークレスポンスが完了する」といった**イベント駆動の明示的待機（Auto-waiting）**を使用してください。

2. 見た目に依存しないテストID・アクセシビリティセレクタの採用

クラス名やHTML階層（例: div > ul > li:nth-child(2)）で要素を指定すると、CSSのリファクタリングでテストが一撃で死にます。 PlaywrightやTesting Libraryが推奨するように、getByRole や data-testid 属性を活用し、実装の詳細とテストを疎結合に保つことが鉄則です。

原則3：フレイキーテストは即時隔離（Quarantine）し、放置しない

テストスイートの中に1本でも「時々落ちるテスト」が存在することを許容してはいけません。

開発者が「あ、このテストはいつものフレイキーだから無視してマージしよう」と考え始めた瞬間、自動テストの価値はゼロになります。本物のバグでCIが赤くなったとしても、見過ごされるようになるからです。

  1. 発見したら即座に隔離: 不安定なテストを発見した場合は、その場でスキップ（隔離用スイートへ移動）し、メインのCIパイプラインを常に「信頼度100%」の状態に維持します。
  2. 原因を特定して再発防止: 待機条件の不足なのか、テストデータ共有による干渉（テスト間の独立性欠如）なのかをログやトレースで分析し、修正されたテストのみをメインラインに復帰させます。
  3. 直せないテストは捨てる勇気: 保守工数が見合わないテストは、無理に残すよりも削除し、別のレイヤー（APIやユニット）で代替できないかを検討します。

まとめ：動くコード以上に「壊れにくいテスト」を設計する

この記事の結論
  • ピラミッド設計を死守: 重いE2Eに頼らず、高速なユニットテストとAPIテストで土台を固める
  • 固定スリープと脆弱セレクタを排除: イベント待機とアクセシビリティ/testidによる疎結合な指定を徹底する
  • フレイキーテストは即隔離: 信頼性を損なう不安定なテストはパイプラインから即座に外し、常に信頼度100%を保つ

テスト自動化の目的は「テストを書くこと」ではなく、「開発チームが安心して高速にリリースを続けられるフィードバックループを作ること」です。

QAAIXでは、今後も現場の泥臭いテスト自動化の課題、ツールの実践的な比較、CI/CDパイプラインとの連携手法を徹底的に深掘りしていきます。