Risk-Based Test Retirement Justification Prompt

This prompt is designed for test architects, QA leads, and SDETs in regulated or safety-critical environments who need to retire test cases without breaking an audit trail. The job-to-be-done is producing a structured, evidence-backed justification document that links each retirement candidate to a risk assessment, identifies alternative coverage, and specifies the required stakeholder sign-offs. It is not a prompt for deciding which tests to retire—that analysis should already be complete. Instead, this prompt takes a pre-analyzed list of retirement candidates and transforms it into a compliance-ready artifact suitable for review by quality assurance, regulatory, or safety assessors.

Use this prompt when you have already identified specific test cases for retirement through redundancy analysis, obsolescence checks, or coverage overlap assessments, and you now need a formal justification package. The prompt requires a detailed input context: the test case identifier, the reason it is a retirement candidate (e.g., 'duplicate of TC-402', 'feature deprecated in v3.2'), a risk classification (e.g., 'Low', 'Medium', 'High'), a description of how the covered behavior is still verified elsewhere, and any relevant traceability links to requirements or hazards. Without this pre-digested input, the model will lack the necessary evidence to ground its justification and will produce vague, un-auditable text.

Do not use this prompt for initial test selection, for low-risk consumer applications where a lightweight changelog entry is sufficient, or in environments where no human review will occur before retirement is finalized. The output is a draft justification for human approval, not an automated decision. If your workflow does not require an evidence trail—for example, a small startup cleaning up a unit test suite with no regulatory oversight—this prompt adds unnecessary process overhead. In those cases, a simpler retirement log or direct deletion with a commit message is more appropriate. After generating the justification, the next step is to route it through your defined approval workflow, archive it alongside the test suite change record, and ensure the retirement is traceable in your test management system.

This prompt template is designed to produce a structured justification for retiring a test case in regulated or safety-critical environments. It forces the model to link the retirement recommendation to a risk assessment, identify coverage alternatives, and specify stakeholder sign-off requirements. The output is intended to serve as an audit artifact, so the prompt demands explicit evidence and a clear chain of reasoning rather than a simple yes/no recommendation.

textCopy
You are a test architect for a regulated software system. Your task is to produce a structured, auditable justification for retiring a specific test case. Every retirement decision must be traceable to a risk assessment and must preserve an evidence trail for compliance review.

## Input
[TEST_CASE_DETAILS]
[RISK_ASSESSMENT]
[COVERAGE_ALTERNATIVES]
[STAKEHOLDER_LIST]

## Constraints
[CONSTRAINTS]

## Output Schema
Return a JSON object with the following structure:
{
  "retirement_recommendation": {
    "test_case_id": "string",
    "recommendation": "RETIRE | RETAIN | DEFER",
    "confidence": "HIGH | MEDIUM | LOW"
  },
  "risk_justification": {
    "risk_level": "LOW | MEDIUM | HIGH | CRITICAL",
    "risk_rationale": "string (explain why the risk of removal is acceptable)",
    "residual_risk": "string (describe any remaining risk after retirement)"
  },
  "coverage_assessment": {
    "covered_by_alternatives": ["list of test case IDs or coverage sources"],
    "coverage_gaps_introduced": ["list any unique assertions or paths lost"],
    "gap_acceptance_rationale": "string (if gaps exist, explain why they are acceptable)"
  },
  "stakeholder_signoff": [
    {
      "role": "string",
      "required": true,
      "signoff_criteria": "string (what this stakeholder must confirm)"
    }
  ],
  "rollback_conditions": ["list of conditions that would trigger test reinstatement"],
  "evidence_trail": {
    "data_sources": ["list of logs, reports, or documents referenced"],
    "analysis_date": "string",
    "analyst_notes": "string (any assumptions or limitations)"
  }
}

## Instructions
1. Base the recommendation solely on the provided [RISK_ASSESSMENT] and [COVERAGE_ALTERNATIVES]. Do not invent risks or coverage.
2. If the risk level is HIGH or CRITICAL, the recommendation must be RETAIN or DEFER unless coverage alternatives fully mitigate the risk.
3. Every stakeholder in [STAKEHOLDER_LIST] must appear in the signoff array with explicit criteria.
4. If any coverage gap is introduced, you must either justify its acceptance or recommend DEFER.
5. Flag any missing information that prevents a confident recommendation in the analyst_notes field.

To adapt this prompt, replace the square-bracket placeholders with your actual inputs. The [TEST_CASE_DETAILS] should include the test case ID, description, purpose, and any historical defect data. The [RISK_ASSESSMENT] should be a pre-computed risk evaluation for the feature area, not something the model invents. The [COVERAGE_ALTERNATIVES] must list other tests, monitoring, or manual checks that cover the same behavior. The [CONSTRAINTS] field is where you inject domain-specific rules, such as regulatory requirements (e.g., "FDA 21 CFR Part 11 requires retention of all verification tests for Class II devices") or organizational policies. If you are using this in a CI pipeline, wire the output into a review queue where a human confirms the recommendation before any test is actually removed from the suite.

This prompt is not a one-shot automation. It is a decision-support tool that must be embedded in a workflow with explicit validation gates, human approval steps, and immutable audit logging. The model produces a structured justification document, but the final retirement decision and sign-off must remain with authorized stakeholders. The implementation harness described here assumes a regulated or safety-critical context where test removal decisions are auditable events, not routine CI optimizations.

Wire the prompt into an application as a multi-step pipeline. First, collect the required inputs: a list of retirement candidate test IDs, their recent execution history (pass/fail/flaky counts, last N runs), coverage maps linking each test to requirements or risk items, and any existing retirement proposals or stakeholder notes. Assemble these into the [TEST_CANDIDATES], [EXECUTION_HISTORY], [COVERAGE_MAPS], and [STAKEHOLDER_CONTEXT] placeholders. Before calling the model, run a pre-validation check to ensure every candidate has a coverage trace; flag any orphan tests with no mapped requirement for manual review. After the model returns the structured justification, apply a post-generation validator that checks: (1) every retirement recommendation includes a risk assessment field, (2) every 'retire' recommendation cites at least one alternative coverage source, (3) no recommendation contradicts the provided coverage map, and (4) the output conforms to the expected JSON schema. Failed validations should trigger a retry with the validator errors injected into [CONSTRAINTS] as explicit fix instructions. After three failed retries, escalate to a human reviewer with the partial output and error log.

The human-in-the-loop step is mandatory for high-risk domains. Route every generated justification to a review queue where an authorized test architect or QA lead can approve, reject, or modify each recommendation. The review interface should display the original inputs, the model's justification, the validator results, and a diff view showing which tests would be removed from the active suite. Every approval action must record: reviewer identity, timestamp, decision per candidate, and any override rationale. Store the complete decision record—inputs, prompt version, model response, validator output, reviewer actions—in an append-only audit log. For regulated environments, this log should be immutable and queryable for compliance reviews. Do not automatically disable or delete tests based on model output alone; the harness should only flag candidates and prepare the justification package for human decision-makers.

Model choice matters here. Use a model with strong structured output capabilities and low hallucination rates on analytical tasks—frontier models with JSON mode or structured output APIs are preferred. Set temperature low (0.0–0.2) to maximize consistency across justification runs. If your test management system has an API, integrate the approved retirement actions directly: after human sign-off, the harness can call the test management API to mark tests as deprecated, move them to an archive suite, or attach the justification document as a permanent annotation. Log every API call with the correlation ID from the audit record. Avoid building this as a chat interface; it should be a controlled, API-driven workflow with no free-form user input reaching the model outside the defined placeholders.

Common failure modes to instrument for: the model may recommend retiring a test that guards a regression not captured in the provided coverage map (false negative risk), may produce vague risk assessments that pass schema validation but lack substantive reasoning, or may fail to identify that two 'redundant' tests actually exercise different environmental conditions. Mitigate these by requiring the validator to flag risk assessments shorter than a minimum character threshold, by periodically sampling and manually reviewing justifications for reasoning quality, and by maintaining a 'do-not-retire' list of tests that have caught critical regressions in the past, checked before any recommendation reaches the review queue.