テストのライフサイクル

継続する検知には理由を持つ

対応する契約や環境が増えれば、必要なテストが増えるのは自然です。目標は有用で費用に見合う検知であり、テスト数の一定化ではありません。保持、今回の実行、過去の成功結果の再利用は別の判断です。保持しているだけで実行しないテストは、現在の障害を検知しません。

実行ティアは環境・時期・予算を、変更範囲に応じた検証は選択・再利用を扱います。一時的なredを許容する開発は、どの境界でgreenを必須にするかを別に定義します。

継続する回帰テストを入れる条件

分類は 継続目的 → 適切なレベル → 実行条件・頻度・予算 → タグ の順で行います。

• 対応中の振る舞い・境界と、継続して検知したい失敗を明示する。

• その失敗を観測でき、十分な既存証拠と不要に重複しないレベルを選ぶ。

• 再実行が必要な変更・環境と、必要な検知時期を説明する。

• 決定性、実行可能な環境、ティア、スイート全体の予算を確認する。

契約・機能・テスト群単位で判断できます。全テストの新しい手書き台帳や個別の人間承認は不要です。既存方針に沿って最初から回帰テストを書くことは通常の開発です。一時検証をゲートへ昇格する場合はルール6に従い、明示的な提案とレビュアーの判断を経て、自己昇格させません。

タグなしの既定値は入場判断後のCIセーフを意味し、すべてのスクリプトを自動で恒久化しません。日付・Issue番号・bugfix は探索のヒントです。名前も改名も寿命を決定しません。

下位層へ移す前に保証を対応づける

同じ最終アサーションでも、同じ境界を保証するとは限りません。元の証拠を 代替する部分／他で担えている部分／残す部分／手放す部分 に分けます。統合時のアサーションマトリクスとバリアント一覧は維持します。

UIを操作して保存し、合計42を比較するE2Eは、計算に加えて配線・変換・永続化・表示を確認しています。値の組み合わせはunitへ移し、残る接続には薄い結合テスト等の証拠を対応づけます。共通境界の代表が多数の安価なケースを支えられる場合もあります。接続の検知を手放すなら、同等と称さず失う保証を記録します。

モジュール化は契約と依存関係を明確にしますが、ディレクトリやリポジトリを分けてもconsumerが独立した証明にはなりません。API名や型が同じでも振る舞いが不変とは限りません。共通fixture・設定・間接依存の変更はconsumerの証拠を失効させ得ます。

ウォーキングスケルトンは同じ統合経路の代表1本を出発点にします。独立した認証・アップロード・native境界には追加の証拠が必要な場合があります。件数制限のために無関係な経路を巨大な1スペックに詰め込まず、値の組み合わせごとにE2Eを増やすことも避けます。

根拠を示して退役する

退役には次のいずれかの判断経路があります。

1. 一時的役割の完了。 移行・作成時の検証が完了し、独立した継続義務が残っていない。必要なら小さな完了記録を残す。

2. 対応契約の終了。 機能・互換性・対応環境が正式に終了した。

3. 代替証拠。 安価な検証・統合・別の検証で、必要な振る舞いと境界を十分に担える。

4. 失敗条件の構造的除去。 不正な状態・経路が生じなくなった理由を示す。書き直しや型の追加だけでは説明にならない。

5. 検知損失の受容。 失う検知・影響・根拠・残余リスクを示し、既存の権限・レビュー方針に沿って決める。これは保証の削減であり同等な置換ではない。

同等の代替テストだけが削除の条件ではありません。一方、古さ、直近の失敗ゼロ、非クリティカル、カバレッジ重複、名前、AIの確信だけでも不要とは証明できません。検出履歴は優先順位の材料にし、履歴不明は不明とします。6か月の履歴や3か月の無事故は自動的な十分条件ではなく、利用・変更・観測可能性によって沈黙の意味が変わります。毎回の完全な履歴収集は不要です。十分な根拠がなければ保持・修正へ戻し、追加調査にも上限を設けます。

現役の契約の証拠を失ったら、verification mapの該当gapを可視化します。十分な証拠のある部分はProvenのままです。受容した未検証リスクは別に記録し、受容だけでProvenにしません。

対照的な例