AIによるテストスイートの精査
調査範囲に上限を設ける
既存レポートと履歴から、費用・保守負担が大きいテスト群を調べます。全件棚卸し、新しい計測サービス、削除件数目標から始めません。定期監査は任意で、予算超過・スイート増加・サポート終了も見直しの契機になります。
目的と予算を決める。 請求額、開発者の待ち時間、flake対応、保守は別の目標です。workflow・suite・期間・調査工数を絞ります。
負担の所在を調べる。 頻度、重複trigger、job・matrix・shard、runner種類、setup・install・build・test・retryを確認します。取得できない値は不明です。
契約と証拠を読む。 確認済みの製品契約と、現状のテストから推測した仕様を区別します。ライフサイクルに沿い、代替証拠・残す境界・失う検知を対応づけます。
対応案を比較する。 維持、flake修正、置換・統合、変更範囲による選択、結果再利用、頻度変更、退役を比較します。削除数を目的にしません。
変更に比例して検証する。 assertion・境界の対応や限定した変更前後比較を使います。難しい場合のfault injection・mutation testingは選択肢であり、全削除の義務ではありません。assertion弱化、skip、filter、ゲートファイル変更にはルール8のopen issue・fresh-context reviewを維持します。候補発見や維持判断に新しいレビューゲートは加えません。
適用後を確認する。 対象の費用・待ち時間・retry・検知の変化を比較し、必要な再検討・撤回条件を置きます。運用を変えていない監査は、実測の削減を達成していません。
AIは調査・提案・既存委任内での実装・独立レビューを担えます。人間が全テストを精読する必要はありません。委任を超える未確定の製品契約やリスク受容は、判断権限のある担当者へ戻します。
候補ごとの最小レポート
suite・契約群単位で記録できます。明確な廃止契約や完全重複は短くし、判断に必要なところだけ詳しくします。
| 項目 | 記録内容 |
|---|---|
| 対象と役割 | ファイル・suite、継続契約か一時検証か、根拠リンク |
| 負担 | 取得できた時間・頻度・retry・保守履歴、実測／概算／不明の区別 |
| 保証対応 | 検知する失敗、代替証拠、残す境界、失う検知 |
| 提案 | 対応と理由 |
| 不確実性とリスク | 未確認の要件、未観測条件、受容が必要な保証削減 |
| 検証とレビュー | 実施した確認、証拠リンク、既存方針による判断 |
| 効果と見直し | 予測と実測、必要な再検討・撤回条件 |
同じものを比較する
workflow経過時間には待ち時間も含まれ、課金はjob実行量とrunner単価に依存します。テスト数・平均ワーカー秒は請求額ではありません。並列度・偏り・共通setup・最遅shardによって、削除してもjob時間が変わらない場合があります。setupや重複triggerのほうが有力な改善対象かもしれません。
検証経路を3つに分けます。
同じスイートの高速化： 件数だけでなくcanonical test identitiesの一致と、CIゲート最適化の実CI環境の証拠を維持します。runner sizingは実行資源を変えます。
置換・統合： 必要なassertionと境界を対応づけ、既存のassertion matrix・variant inventoryを維持します。
頻度低下・退役： 遅れる・失われる検知と、権限に沿ったリスク判断を示します。同等保証とは呼びません。
20分のjobを非同期化すればマージ待ちを20分減らせても、20 runner-minutesを使うままです。一時的なredを許容する開発は開発の待ちを変えますが、自動で請求を減らしません。変更範囲に応じた検証には別途、入力妥当性の条件があります。ここでは削減率を前提にしません。