test-reliability

テスト信頼性のガバナンス（test-reliability）

テストスイート自体の安定性を管理し、このテストの結果はまだ信頼できるかという問いに答えます。単一のテストケースの成否が不安定であること、再実行で成功すること、夜間の全件実行をリトライで成功扱いにしていること、リリースゲートが flaky 疲れによる大量の失敗にさらされていることなどが、このスキルの管理対象です。本スキルはスイートレベルで「判定 → 隔離 → 根本原因 → ゲート → 健全度」のサイクルを回すもので、個々の実行フローを置き換えるものではありません。

• 入力：失敗／合格への反転の履歴（CI 実行記録、再実行ログ、triage 振り分け表の D 類項目）、スイート一覧と実行統計。プロジェクトに .qa/ が存在する場合は、まず flaky-tests テーマを読みます（qa-memory に蓄積された過去の判定）。
• 出力（ファイルに保存）：《信頼性レポート_{スイート}_{日付}.md》——flaky 項目の一覧（判定 × 根本原因分類 × 対処 × 状態。フィールドが1つでも欠けていればレポートは不適合）＋スイート健全度の機械可読なサマリー（フィールドの仕様は references/flaky-playbook.md の第 5 節を参照。../core/report-template.md の機械可読セクションに準拠）。判定結果を蓄積し（.qa/ への記録に値する発見を選定）、qa-memory ワークフローに引き渡します。
• 適用範囲（三層の役割分担。同じ出典：../core/triage.md 第 7 節）：実行中の個別失敗に対する即時の判定（first-run-flaky ルール、待機戦略）→ 各実行スキルのエンジニアリング規約。一括した失敗の初回分類と振り分け → ../core/triage.md。確認済みバグの根本原因／影響／修正案 → bug-analysis。本スキルは「スイートとゲート」の層を管理します——個別の判定後に行う、複数回にわたる追跡、根本原因の分類、隔離戦略、リトライの意味付け、健全度の管理です。

When to Use

• ユーザーから「このテストケースはなぜ成否が不安定なのか／これは flaky なのか／再実行で成功したら修正済みと見なせるのか」と聞かれたとき
• CI の夜間スイートをリトライで成功扱いにしており、リトライ戦略の判断や隔離（quarantine）ゲートの策定が必要なとき
• スイート健全度（flaky 率、隔離数、リトライ救済率）や、リリースゲートの信頼性を示す根拠が必要なとき
• 振り分け表の D 類（不安定）項目が複数回にわたって蓄積し、根本原因の分類と対策のスケジュール策定が必要なとき
• プロジェクトで「テストスイートの信頼性」の基準を定め、どのようなスイート状態ならリリースの根拠として認められるか決めるとき

When NOT to Use

• 1回の実行における個別失敗の即時対応（スクリーンショット、再実行による判定、待機の段階的な緩和）→ 各実行スキルのエンジニアリング規約（例：automated-e2e-testing）
• 1回の実行終了時に失敗が 3 件以上ある場合の一括判定・振り分け → ../core/triage.md（結論が D 類となった項目を複数回にわたって追跡する際は、本スキルに戻ります）
• 確認済みバグの根本原因の特定、影響分析、修正案 → bug-analysis
• テストケース自体の作成 → test-case-writing。回帰テストの範囲決定 → regression-testing
• 1回の実行レポート → ../core/report-template.md（本スキルの健全度サマリーは、その機械可読セクションに準拠します）

コアモデル：安定性を表す三層の意味

1. テストケースレベル：個々のテストケースについて「真の失敗か、ノイズか」を判定します——根拠は感覚ではなく、再実行マトリクスです（ワークフロー一）。
2. スイートレベル：テストケース群の信頼性の水準です——健全度指標で評価します（ワークフロー五）。
3. ゲートレベル：スイートの結果がリリースの根拠として持つ意味です——リトライでの成功、隔離によるスキップ、未実行をそれぞれどう扱うかを定めます（ワークフロー四）。

この三層を混同してはいけません。個別の判定が正しい ≠ スイートが健全。スイートが全件成功 ≠ ゲートの根拠として適格（リトライ頼みで成功扱いになっている可能性があります）。

ワークフロー一：flaky の判定と根本原因の四分類

1. 判定（原因の推定より先に行う）：テストケースが初回に失敗し、同じ条件で再実行して成功した場合、first-run-flaky と判定します。安定した成功とは見なしません——再実行は判定のためだけに行い、常態的な成功手段にしてはいけません（同じ出典：playwright-conventions §11、../core/triage.md の D 類。規則は共通）。証拠が不十分な場合は「不明」と明記し、結論を捏造してはいけません。
2. 再実行マトリクス（根本原因を推定するための証拠）：flaky と判定したテストケースについて、マトリクスに従って証拠を集めます——同じ条件で再実行／隔離して再実行（そのケースだけを実行）／クリーンな環境で再実行（新しいコンテナ／新しいディレクトリ）／順序を含めて再実行（前後のテストケースと順番に実行）。マトリクスの結果を根本原因の四分類に当てはめる際は、この時点で references/flaky-playbook.md を参照します（第 2～3 節：判定ツリー＋証拠表）。
3. 根本原因の四分類（分類名と典型的な証拠は playbook 第 3 節、修正パターンは playbook 第 4 節を参照）：
   • S1 待機不足・タイミングの問題：非同期処理の待機不足、ポーリング間隔、アニメーション／遅延読み込み——隔離して再実行しても断続的に失敗する
   • S2 共有状態とテスト間の依存関係：データの残留、実行順序への依存、グローバルシングルトンの汚染——隔離して再実行すると安定し、順序を含めて再実行すると失敗する
   • S3 環境とサードパーティの不安定さ：依存サービスのタイムアウト、証明書／アカウントの期限切れ、リリース時間帯の重複、リソース容量——クリーンな環境で再実行すると問題が消える、または特定の時間帯に失敗が集中する
   • S4 並行処理とリソースの競合：並列実行時のポート／ファイル／データベースの競合——並列実行を無効にすると問題が消える
4. 成果物：flaky 項目ごとに1行の記録を作成します——テストケース × 判定 × 根本原因の分類 × 証拠（再実行マトリクスの結果）× 対処 × 状態。6つのフィールドが1つでも欠けていれば、レポートは不適合です（実行可能性を保つためのルール：判定できない項目には管理上の価値がありません）。

ワークフロー二：隔離と短期的な対処

• 短期的な隔離：修正の着手時期が先になる場合は、test.fixme（または同等の quarantine マーカー）を付けて、メインブランチの成功結果を汚染しないようにします。隔離は可視化する必要があります——隔離一覧に登録し、気付かれないままスキップすることを禁止します。登録されていない test.fixme の散在も隔離に該当します（quarantined_count と一覧の両方に含めます）。「未登録」であること自体が、隔離の可視化に関するコンプライアンス上の問題です。
• 複数回にわたる追跡：D 類項目を振り分け表に記録し、複数回にわたって追跡します。3 回以上の実行にわたったら、根本原因の修正にエスカレーションします（同じ出典：../core/pipeline-integration.md のフィードバック規則）——隔離は先延ばしであり、ゴールではありません。
• ゲートの意味：隔離されたテストケースは合格率の分母に含めませんが、レポートと機械可読サマリーには必ず記載します（quarantined_count）。「隔離後に全件成功」を「スイートが健全」と表現してはいけません。

ワークフロー三：根本原因の修正パターン

四分類に応じて、playbook 第 4 節の修正パターン集（各分類につき、アンチパターンを含む 3～5 個のパターン）を適用します。

• S1 → 待機戦略の段階的な緩和（目標状態を明示して待機し、sleep とタイムアウトの延長は禁止）
• S2 → テストデータファクトリーの分離＋後片付け＋一意な命名（同じ出典：../core/methods/data-factory.md）
• S3 → 環境アサーションの前倒し＋リリース時間帯の分散＋依存関係のモック境界
• S4 → リソースの専有宣言＋並列実行の前提条件の確認（自前でのデータ作成／後片付け／一意な命名を個別に確認）

修正の完了 ≠ 問題のクローズ：修正後、元の再実行マトリクスに従って安定性を再検証します（N 回連続ですべて成功することを推奨します。N の値は playbook 第 4.0 節を参照）。判定結果を .qa/ に記録します（ワークフロー五のステップ 3）。

ワークフロー四：リトライ戦略とゲートの意味（正確な説明を徹底するルール）

• リトライで成功 ≠ 修正済み：リトライで成功しても、「失敗が断続的である」ことを示すだけで、修正の証拠にはなりません。リトライで救済されたテストケースは retry_passes に計上し、初回成功（clean_passes）とは分けて集計します。
• リトライ設定の意味：ローカルでリトライをゼロにして問題を顕在化させます。CI ではリトライは最大 1 回までです——retries を増やしたりタイムアウトを延長したりしてテストケースを成功扱いにすることは禁止です。retries の増加を管理手段とすることは、ノイズをシグナルとして数えることにあたります。必ず却下し、代替案（隔離＋根本原因修正のスケジュール策定）を提示してください。
• リリースゲートの根拠としての意味：リリースの根拠とするスイート結果には、初回合格率、リトライ救済数、隔離数の3項目を明記する必要があります。いずれか1つでも欠けていれば、ゲートの根拠として不適合です。
• 最終判断は人が行います。ユーザーには証拠と選択肢（修正／隔離／上申）を提示し、「問題を抱えたままリリースしてよい」と代わりに判断してはいけません。

ワークフロー五：スイート健全度のレポートと知見の蓄積

1. 健全度指標（定義と機械可読形式は playbook 第 5 節を参照）：flaky_rate（flaky 項目数／テストケース総数）、quarantined_count、retry_pass_rate（リトライ救済数／合格数）、repeat_fail_count（複数回にわたり 3 回以上修正されていない項目数）
2. ファイルに保存：《信頼性レポート_{スイート}_{日付}.md》に項目ごとの一覧と機械可読サマリーを記載します（../core/report-template.md の機械可読セクションの仕様に準拠）。健全度の推移を前回のレポートと比較します。
3. 知見の蓄積：「3 か月基準」を満たす発見（例：特定のサードパーティ依存先が毎週火曜日にリリースし、揺らぎが発生する）→ qa-memory に引き渡し、flaky-tests テーマに記録します。汚染を防ぐためのルールも同じ出典です——「この失敗は環境ノイズなのでリトライ可能」という項目が事実に反していれば、将来のあらゆるセッションに実際の欠陥を見逃させることになります。蓄積する項目には再実行マトリクスの証拠を必ず添付してください。

判定基準（レポートの適合性 ＝ 実行可能性）

• flaky の各記録に6つのフィールド（テストケース／判定／根本原因の分類／証拠／対処／状態）がすべてそろっていること
• 判定では再実行マトリクスの結果を引用すること。「経験上これは flaky」のような表現は禁止
• リトライに関する結論では clean_passes と retry_passes を区別すること
• 根本原因は四分類のいずれかに分類すること。分類が「不明」の場合は、その旨を明記し、次に行う証拠収集アクションを提示すること

速查

场景	动作	禁止
首跑失败原样重跑通过	判 first-run-flaky，进工作流一定性	当作稳定通过放行
重跑绿了，开发说"修好了"	要求给出根因与修复 diff；无则维持隔离	重试绿当修复证据
夜间全量靠 retries=3 撑绿	驳回；给隔离+排期方案与诚实门禁语义	调大 retries/超时变绿
隔离清单越攒越长	升级：≥3 轮未修条目上抛排期	静默跳过或删除用例
发布前套件"全绿"	核三项：首次通过率/重试救回/隔离数	只看最终绿就放行

反模式

反模式	后果	替代
重跑变绿就放过（不标 D 不追踪）	flaky 混入绿灯名单，覆盖虚减，真回归随机漏网	D 类跨轮追踪，≥3 轮升级修根因（../core/triage.md 第 5 节）
调大 retries/超时"治"flaky	噪声计成信号，套件变慢且更不可信	复跑矩阵定位根因类，按 playbook 修复模式处置
静默删除 flaky 用例	无声减覆盖，且删除的是最会报警的哨兵	隔离（fixme/quarantine）+ 排期修复 + 报告可见
健康度只报"通过率 100%"	掩盖重试救回与隔离，门禁证据失真	三项分开统计（clean/retry/quarantine），机读摘要齐备
flaky 判定凭印象不走复跑矩阵	误杀真缺陷或放生噪声	判定必须挂矩阵证据；不足则显式"未知"+下一步取证

在体系中的位置

• ../core/triage.md：分流层 D 类条目是本 skill 的主要输入；本 skill 是其"套件级治理"的下游
• ../core/pipeline-integration.md：CI 回流闭环与 headless 语义；本 skill 的隔离/健康度是其 D 类处置的展开
• ../core/report-template.md：健康度机读摘要的挂靠规范
• ../core/test-type-matrix.md：轴 7 防 flaky 条款的治理侧展开
• qa-memory：flaky 判定的跨会话沉淀（文字协作，非依赖）；沉淀条目自带投毒防线要求