Obsolete Test Retirement Recommendation Prompt

This prompt is designed for SDETs and test architects who need to make a data-backed case for retiring a specific test case. The core job-to-be-done is generating a structured justification that links the retirement recommendation to concrete evidence: traceability gaps, code coverage overlap, stale requirement mappings, or prolonged periods of zero defect yield. It is not a bulk suite scanner; it works on one test case at a time, producing a detailed impact assessment suitable for stakeholder review or compliance audit trails.

Use this prompt when you have already identified a candidate test case and gathered its supporting evidence—such as its last execution results, linked requirements, code path coverage data, and defect history. The prompt requires you to provide this context explicitly via the [TEST_CASE_DETAILS] and [EVIDENCE_CONTEXT] placeholders. Do not use this prompt for initial discovery of redundant tests; use the Redundant Test Case Identification Prompt for that. Avoid using it when the test case guards an untracked regression or a critical safety property that lacks formal documentation, as the model will not infer undocumented risk.

The output is a structured retirement justification containing a coverage impact assessment, risk rationale, and explicit rollback conditions. Before acting on the recommendation, you must validate that no unique assertion or untracked regression path is silently dropped. The prompt includes a [REVIEW_CHECKLIST] placeholder to enforce human sign-off, ensuring the final decision remains auditable. If the test case belongs to a regulated system, route the output through your compliance review workflow before any retirement action is taken.

This section provides the core prompt template for the Obsolete Test Retirement Recommendation workflow. The template is designed to be copied directly into your prompt library, IDE, or orchestration layer. It uses square-bracket placeholders for all dynamic inputs, making it straightforward to wire into a CI/CD pipeline, a test management system, or a manual review queue. The prompt forces the model to justify every retirement recommendation with traceability evidence, coverage impact analysis, and explicit rollback conditions—preventing the removal of tests that guard against untracked regressions.

textCopy
You are a senior SDET analyzing a test case for potential retirement. Your task is to determine whether [TEST_CASE_ID] should be retired from the test suite and to produce a structured recommendation with evidence.

## INPUT
- Test Case: [TEST_CASE_ID]
- Test Name: [TEST_NAME]
- Test Steps: [TEST_STEPS]
- Assertions: [ASSERTIONS]
- Last Execution Status: [LAST_STATUS]
- Defects Found (last 12 months): [DEFECT_HISTORY]
- Linked Requirements: [REQUIREMENT_IDS]
- Code Paths Exercised: [CODE_PATHS]
- Current Feature Status: [FEATURE_STATUS]
- Maintenance History: [MAINTENANCE_HISTORY]

## CONTEXT
- Suite Health Goals: [SUITE_HEALTH_GOALS]
- Risk Tolerance: [RISK_TOLERANCE]
- Regulatory Constraints: [REGULATORY_CONSTRAINTS]
- Recent Code Changes: [RECENT_CODE_CHANGES]

## CONSTRAINTS
- Do not recommend retirement if the test covers a unique code path that is still active.
- Do not recommend retirement if the test has caught a defect in the last [DEFECT_WINDOW_MONTHS] months.
- If the linked requirement is deprecated but the code path is still exercised by another feature, flag the gap instead of recommending retirement.
- For any retirement recommendation, you must specify a rollback condition.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "recommendation": "RETIRE" | "KEEP" | "REFACTOR" | "INVESTIGATE_FURTHER",
  "confidence": "HIGH" | "MEDIUM" | "LOW",
  "rationale": "string explaining the primary reason for the recommendation",
  "coverage_impact": {
    "unique_coverage_lost": ["list of assertions or paths that would no longer be tested"],
    "alternative_coverage_exists": true | false,
    "alternative_tests": ["test IDs that cover the same risk"]
  },
  "risk_assessment": {
    "regression_risk": "HIGH" | "MEDIUM" | "LOW",
    "risk_rationale": "string explaining the risk level"
  },
  "rollback_conditions": ["specific conditions that would require restoring this test"],
  "evidence": {
    "requirement_status": "ACTIVE" | "DEPRECATED" | "UNKNOWN",
    "code_path_status": "ACTIVE" | "DEAD" | "UNKNOWN",
    "defect_history_relevant": true | false
  },
  "stakeholder_approval_required": true | false,
  "suggested_reviewers": ["roles or individuals who should approve before retirement"]
}

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## INSTRUCTIONS
1. Compare the test assertions against the linked requirements and current feature status.
2. Check whether the code paths exercised are still reachable in the current codebase.
3. Review defect history to determine if this test provides unique regression protection.
4. If coverage is duplicated elsewhere, verify that the alternative tests actually assert the same conditions.
5. If you cannot determine code path status from the provided information, set recommendation to INVESTIGATE_FURTHER.
6. For any RETIRE recommendation, provide at least one specific rollback condition.

Adapting the template for your environment: Replace each square-bracket placeholder with data from your test management system, CI pipeline, or manual analysis. The [FEW_SHOT_EXAMPLES] placeholder should be populated with 2-3 example recommendations showing correct RETIRE, KEEP, and INVESTIGATE_FURTHER outputs for your domain. If your organization uses a different risk taxonomy, adjust the enum values in risk_assessment.regression_risk and confidence to match your internal terminology. For regulated environments, add a [COMPLIANCE_EVIDENCE] field to the INPUT section and require explicit regulatory citations in the rationale. The [DEFECT_WINDOW_MONTHS] constraint should be set based on your release cadence—typically 6-12 months for quarterly releases, or 3 months for continuous deployment teams. Before deploying this prompt to an automated pipeline, validate that the output JSON conforms to your schema using a programmatic validator, and log every retirement recommendation for auditability.

This prompt is designed to be called programmatically as part of a test suite maintenance pipeline, not as a one-off chat interaction. The implementation harness must supply structured evidence about each candidate test case, invoke the model, validate the structured output, and route the recommendation to the appropriate review queue. Because the prompt recommends removing safety assets, the harness must treat every retirement recommendation as a draft requiring human approval before any test is deleted or disabled.

Wire the prompt into an application by first assembling the required inputs for each test candidate: the test case identifier, its current steps and assertions, the traceability links to requirements or code paths it claims to cover, recent execution history (pass/fail/flaky rates over the last N runs), and any known coverage overlap with other tests. Package these into the [TEST_CASE_PROFILE] placeholder as a structured JSON block. Set [CONSTRAINTS] to enforce the output schema and require explicit coverage gap analysis. On the model side, choose a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set response_format to json_schema where available, using the retirement recommendation schema defined in the prompt. Implement a validation layer that checks: (1) the output parses as valid JSON matching the expected schema, (2) the retirement_recommendation field is one of the allowed enum values, (3) every coverage_gap entry references a specific requirement or code path, and (4) the rollback_conditions field is non-empty when the recommendation is retire. If validation fails, retry once with the validation errors injected into the prompt as additional context. If the second attempt fails, escalate to a human reviewer with the raw output and validation failure details.

Log every invocation with the test case ID, model version, prompt version, raw response, validation result, and final recommendation. This audit trail is essential for compliance reviews and for debugging false-positive retirement suggestions. Route retire recommendations to a review queue where an SDET or test architect must confirm or reject the recommendation before any CI configuration change. Route retain and investigate recommendations to a lower-priority backlog for periodic review. Never automate the actual deletion or disabling of tests based solely on model output—the harness should produce a signed-off change ticket that a human applies. For teams using test management systems like TestRail, Zephyr, or Xray, the harness should update the test case status field to pending_retirement_review and attach the full recommendation as evidence, rather than modifying the test directly.