リグレッションテストを腐らせない追加と削除の基準
「バグが出たら再発防止のテストを足す」。どのチームでも正しいとされる運用ですが、足し続けるだけのリグレッションテストは、いずれ腐ります。実行に40分かかる、毎回どれかが落ちる、落ちても誰も見ない。こうなったテストスイートはバグを止める網ではなく、マージ前に待たされるだけの儀式です。
この記事では、テスト工程の中でもリグレッションテストの「育て方」と「間引き方」に絞って、追加基準と削除基準を運用ルールとして決める方法を紹介します。
リグレッションテストが腐る3つの症状
- 実行時間の膨張：半年前は5分だったCIが25分になり、開発者がローカルで回さなくなる
- フレーキーの常態化：「またあのテストか」と再実行ボタンを押すのが日課になる
- 意図の喪失：何を守っているテストなのか誰も説明できず、壊れても直さず skip される
どれも「追加するときの基準」と「消すときの基準」が無いことが原因です。足すルールだけがあり、減らすルールが無いため、テストは単調に増え続けます。
追加基準：「バグが出たらテストを足す」を具体化する
ルールを「足す」だけにすると、同じ内容のE2Eテストが何本も積み上がります。追加時に次の3点を必ず決めます。
1. 最も下の層で書く
再現に画面操作が要ったバグでも、原因が計算ロジックならユニットテストで書けます。E2E は「画面をまたぐ流れが壊れた」ときだけに限定します。目安は「原因の箇所を直接呼べる一番下の層」です。
2. テスト名にバグの識別子を入れる
it("割引率100%のとき合計が負にならない（Issue #482）", () => {
expect(calcTotal({ price: 1000, discountRate: 1.0 })).toBe(0);
});Issue 番号があれば、半年後に「このテストは何を守っているのか」を1クリックで辿れます。意図を失ったテストを作らない最も安い方法です。
3. 既存テストの拡張で済まないか確認する
境界値が1つ抜けていただけなら、新しいテストファイルではなく既存のパラメータ化テストに1行足せば十分です。
削除基準：消していいテストを見つける
「テストを消す」には心理的な抵抗があります。だからこそ、判断を個人の勇気に任せず基準として明文化します。
削除・統合の候補になる4条件
- 下位層で同じことを検証している：ユニットで境界値を網羅しているのに、E2E でも同じ入力を試している
- 対象の機能がもう存在しない：廃止した画面のテストが、スタブで無理やり通っている
- 直近90日で一度も失敗していない E2E で、かつ下位層でカバーされている：失敗しないこと自体は削除理由になりませんが、重複と組み合わさると候補になります
- フレーキー率が高く、2週間以内に直す担当者がつかない：信用されないテストは、無いより悪い状態です
重複テストの見つけ方
- カバレッジをテスト単位で出し、同じ行集合だけを通っているテストを並べる（Jest / Vitest なら
--coverageをテストファイルごとに実行して比較） - CI のテスト結果履歴から、失敗率と所要時間の上位10件を毎月出す
- テスト名で grep し、同じ Issue 番号や同じ画面名が複数の層に出てくるものを探す
運用に落とす：月1回30分の「間引き会」
基準を決めても、見直す場がなければ動きません。おすすめは月1回・30分・参加者2〜3人の短い会です。
- 所要時間の上位10件と、フレーキー率の上位10件を画面に出す
- それぞれに「残す／下の層に移す／統合する／消す」のどれかを付ける
- 「消す」と決めたものは、その場で PR を作る（次回に持ち越さない）
- スイート全体の実行時間を記録し、前月と比較する
最初の数回で候補に挙がりやすいのは、「ユニットテストでも同じ境界値を見ている E2E」です。E2E は1本あたりの実行時間が長いため、ここを下の層に寄せるだけでも所要時間の短縮が目に見えて表れます。削った月にリグレッションの見逃しが増えていないかも、あわせて記録しておくと判断の根拠になります。
よくある失敗
- skip で逃げる：
it.skipは削除の先送りです。skip のまま30日経ったら消す、と期限を決めます - カバレッジ率だけを守る：数字を守るために意味の薄いテストを残すと、実行時間だけが増えます
- 消す人が1人に偏る：その人が異動した瞬間に元に戻ります。基準を文書化して誰でも判断できるようにします
Bugoon での実践
追加基準の「最も下の層で書く」は、バグの原因をどれだけ早く特定できるかにかかっています。Bugoon のウィジェットで報告されたバグには、スクリーンショットとアノテーション、操作ステップ、Console ログやネットワークエラーが自動で添付されるため、E2E で再現を組み立てる前に原因の層に当たりをつけやすくなります。
レポートは GitHub Issue として連携されるので、その Issue 番号をそのままテスト名に入れれば、テストからバグ報告の画面まで辿れます。MCP サーバー経由で Claude Code や Cursor にバグ修正を任せる場合も、「修正と同時に Issue 番号入りの回帰テストを追加する」を指示に含めておくと、追加基準を自然に守れます。
今後、修正済みのバグに対応するテストがあるかどうかをレポート側に記録できると、リグレッション対策の抜けがカンバンボード上で見えるようになり、さらに扱いやすくなりそうです。