regression-testing

リグレッションテスト

<default_to_action> 既存機能が変更によって壊れていないことを確認する場合：

1. 変更内容を分析する（git diff、影響分析）
2. 変更内容とリスクに基づいてテストを選択する（すべて実行しない）
3. 優先順位に沿って実行する（スモーク → 選択的 → 全体）
4. 実行を最適化する（並列化、シャーディング）
5. テストスイートの健全性を監視する（不安定さ、実行時間）

クイックリグレッション戦略：

• コミットごと：スモークテスト＋変更したコードのテスト（5～10分）
• 毎晩：拡張リグレッション（30～60分）
• リリース前：リグレッションテスト全体（2～4時間）

重要な成功要因：

• 賢いテスト選択により、10％の時間でリグレッションの90％を検出できます
• 不安定なテストは、削減できる時間より多くの時間を浪費します
• 本番環境のバグはすべてリグレッションテストにします </default_to_action>

クイックリファレンスカード

使用するタイミング

• コードを変更した後
• リリース前
• 依存関係の更新後
• 環境の変更後

テスト選択の戦略

戦略	方法	削減率
変更ベース	Git 差分の分析	70～90％
リスクベース	影響度に基づく優先順位付け	50～70％
履歴ベース	頻繁に失敗するテスト	40～60％
時間予算ベース	固定の時間枠	可変

---

変更ベースのテスト選択

// Analyze changed files and select impacted tests
function selectTests(changedFiles: string[]): string[] {
  const testsToRun = new Set<string>();

  for (const file of changedFiles) {
    // Direct tests
    testsToRun.add(`${file.replace('.ts', '.test.ts')}`);

    // Dependent tests (via coverage mapping)
    const dependentTests = testCoverage[file] || [];
    dependentTests.forEach(t => testsToRun.add(t));
  }

  return Array.from(testsToRun);
}

// Example: payment.ts changed
// Runs: payment.test.ts, checkout.integration.test.ts, e2e/purchase.test.ts

---

CI/CD との統合

# .github/workflows/regression.yml
jobs:
  quick-regression:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - name: Analyze changes
        id: changes
        uses: dorny/paths-filter@v2
        with:
          filters: |
            payment:
              - 'src/payment/**'
            auth:
              - 'src/auth/**'

      - name: Run affected tests
        run: npm run test:affected

      - name: Smoke tests (always)
        run: npm run test:smoke

  nightly-regression:
    if: github.event_name == 'schedule'
    timeout-minutes: 120
    steps:
      - run: npm test -- --coverage

---

エージェント主導のリグレッション

// Smart test selection
await Task("Regression Analysis", {
  pr: 1234,
  strategy: 'change-based-with-risk',
  timeBudget: '15min'
}, "qe-regression-risk-analyzer");

// Returns:
// {
//   mustRun: ['payment.test.ts', 'checkout.integration.test.ts'],
//   shouldRun: ['order.test.ts'],
//   canSkip: ['profile.test.ts', 'search.test.ts'],
//   estimatedTime: '12 min',
//   riskCoverage: 0.94
// }

// Generate regression test from production bug
await Task("Bug Regression Test", {
  bug: { id: 'BUG-567', description: 'Checkout fails > 100 items' },
  preventRecurrence: true
}, "qe-test-generator");

---

エージェント連携のヒント

メモリの名前空間

aqe/regression-testing/
├── test-selection/*     - Impact analysis results
├── suite-health/*       - Flakiness, timing trends
├── coverage-maps/*      - Test-to-code mapping
└── bug-regressions/*    - Tests from production bugs

フリートの連携

const regressionFleet = await FleetManager.coordinate({
  strategy: 'comprehensive-regression',
  agents: [
    'qe-regression-risk-analyzer',  // Analyze changes, select tests
    'qe-test-executor',             // Execute selected tests
    'qe-coverage-analyzer',         // Analyze coverage gaps
    'qe-quality-gate'               // Go/no-go decision
  ],
  topology: 'sequential'
});

---

関連スキル

• risk-based-testing - リスクベースの優先順位付け
• test-automation-strategy - 自動化ピラミッド
• continuous-testing-shift-left - CI/CD との統合

---

覚えておくこと

エージェントを使用する場合： qe-regression-risk-analyzer は、実行時間の10％で欠陥の90％を検出できる、インテリジェントなテスト選択を提供します。エージェントは本番環境のバグからリグレッションテストを自動生成します。

スキルの組み合わせ

• テストが失敗する場合 → /test-failure-investigator を使用して根本原因を診断します
• バグを報告する場合 → /bug-reporting-excellence を使用して適切にバグを報告します
• テストを選択する場合 → /risk-based-testing を使用してリスクベースで優先順位を付けます

注意点

• 選択するよう指示しても、エージェントはデフォルトで「すべて実行」するため、--affected またはファイルリストで明示的に範囲を制限します
• 変更ベースの選択では推移的な依存関係を見落とします。モデルの変更が、3段階離れたコントローラーテストを壊すことがあります
• リグレッションテストスイートに含まれる不安定なテストは、テストの不足よりも早く信頼を損ないます。スキップせず、すぐに隔離します
• テストを実行していないだけなのに、エージェントが「リグレッション 0 件」と報告することがあります。合否だけでなく、出力でテスト数を確認します
• コンテナでリグレッションテスト全体を実行すると、メモリ不足になることがよくあります。CI 環境では --workers=2 と --shard を使用します