Low-Value Test Detection and Removal Prompt

This prompt is designed for test architects and SDETs who need to identify test cases with low defect yield, minimal coverage contribution, or disproportionately high maintenance cost. It produces a prioritized retirement candidate list with cost-saving estimates and coverage-preservation verification steps. Use this prompt when you have access to test execution history, failure records, coverage data, and maintenance metadata. The prompt assumes you can provide structured input about each test candidate and that a human reviewer will validate retirement recommendations before any test is removed from the suite.

Do not use this prompt for flaky test detection alone. Flaky tests—those that fail intermittently due to environmental instability, race conditions, or infrastructure flakiness—require a different analytical approach. If environmental instability is a confounding factor in your suite, combine this prompt with a flaky test classification prompt first, then feed only stable-but-low-value candidates into this retirement workflow. Similarly, do not use this prompt when you lack coverage traceability data. Without a mapping between tests and the requirements, code paths, or risk areas they cover, the model cannot reliably assess whether a test's coverage is truly redundant or uniquely guards an untracked regression. The prompt's value depends on structured evidence: execution frequency, pass/fail history, defect linkage, coverage maps, and maintenance event logs.

The ideal user is a test architect or senior SDET who owns suite health over time and can interpret the retirement recommendations against team context. The prompt is not a one-click removal tool. Every retirement candidate must pass human review, and the output includes explicit verification steps—such as confirming that no unique assertion is silently dropped and that rollback conditions are defined—before any test is removed from CI. If your organization operates in a regulated or safety-critical domain, pair this prompt with the Risk-Based Test Retirement Justification Prompt to produce the audit trail and stakeholder sign-off evidence required for compliance review.

This prompt template is designed to be dropped into your AI workflow when you need to analyze a test suite for low-value candidates. It expects structured inputs describing your test cases, their execution history, and coverage mappings. The prompt instructs the model to act as a test architect, applying cost-benefit reasoning to each candidate while requiring explicit evidence for every removal recommendation. Before using this in production, you must replace each square-bracket placeholder with real data from your test management system, CI pipeline, and coverage reports. The output is a prioritized JSON list suitable for ingestion into your test maintenance backlog or review queue.

textCopy
You are a senior test architect analyzing a software test suite for low-value tests that should be considered for retirement. Your goal is to reduce maintenance burden and execution cost while preserving risk coverage.

## INPUT DATA

### Test Suite Context
- Application domain: [APPLICATION_DOMAIN]
- Regulatory requirements: [REGULATORY_REQUIREMENTS]
- Risk areas: [RISK_AREAS]

### Test Cases for Analysis
[TEST_CASES]
<!-- Provide a JSON array of test case objects with fields: id, name, description, covered_requirements, covered_code_paths, average_execution_time_seconds, failure_count_last_90_days, defect_count_last_90_days, flakiness_score_0_to_1, last_modified_date, maintenance_hours_last_quarter, created_date -->

### Coverage Map
[COVERAGE_MAP]
<!-- Provide a JSON object mapping requirement IDs and code paths to the test case IDs that cover them -->

### Constraints
[CONSTRAINTS]
<!-- Specify any tests that must be preserved, minimum coverage thresholds, or compliance requirements -->

## OUTPUT SCHEMA

Return a JSON object with the following structure:
{
  "analysis_date": "ISO date",
  "suite_summary": {
    "total_tests_analyzed": number,
    "total_execution_time_seconds": number,
    "total_quarterly_maintenance_hours": number
  },
  "retirement_candidates": [
    {
      "test_id": "string",
      "test_name": "string",
      "retirement_priority": "high" | "medium" | "low",
      "value_score_0_to_1": number,
      "rationale": "string explaining why this test is low-value",
      "cost_savings": {
        "execution_time_saved_seconds": number,
        "quarterly_maintenance_hours_saved": number,
        "estimated_annual_savings_usd": number
      },
      "coverage_impact": {
        "requirements_losing_all_coverage": ["requirement_id"],
        "code_paths_losing_all_coverage": ["code_path"],
        "coverage_preserved_by": ["test_id"]
      },
      "risk_assessment": "low" | "medium" | "high",
      "recommended_action": "retire" | "merge_and_retire" | "keep",
      "merge_target_test_id": "string or null"
    }
  ],
  "preserved_tests": [
    {
      "test_id": "string",
      "preservation_reason": "string"
    }
  ],
  "coverage_gaps_introduced": [
    {
      "requirement_or_path": "string",
      "previously_covered_by": ["test_id"],
      "gap_severity": "low" | "medium" | "high" | "critical",
      "mitigation": "string"
    }
  ],
  "verification_steps": [
    "string describing a step to validate the retirement plan before execution"
  ]
}

## EVALUATION RULES

1. A test is low-value if it has: low defect yield (few defects found relative to execution frequency), coverage fully duplicated by other tests, high maintenance cost relative to value, or tests features that rarely change and have low risk.
2. Do NOT recommend retirement if: the test is the sole coverage for a requirement or code path, the test covers a regulatory requirement, the test has found critical defects in the past year, or the test covers a high-risk area with no alternative coverage.
3. For each retirement candidate, identify which other tests preserve the same coverage. If no other test covers the same paths, flag the coverage gap explicitly.
4. Prioritize candidates by cost savings potential (execution time + maintenance hours) multiplied by confidence that coverage is preserved.
5. Flag any candidate where retirement would introduce a coverage gap, even if the gap is low severity.

## CONSTRAINTS
- Do not recommend retiring more than [MAX_RETIREMENT_PERCENTAGE]% of the total suite in a single analysis.
- Preserve all tests listed in: [PRESERVED_TEST_IDS]
- Maintain minimum coverage of [MIN_COVERAGE_PERCENTAGE]% for each requirement category.
- If regulatory requirements apply, require explicit human review before any retirement affecting those requirements.

## OUTPUT FORMAT
Return ONLY valid JSON. No markdown fences, no commentary outside the JSON object.

To adapt this prompt for your environment, start by populating the [TEST_CASES] placeholder with a JSON export from your test management system. Include at minimum the fields specified in the comment—execution time, defect history, and coverage mappings are essential for the cost-benefit analysis to be accurate. The [COVERAGE_MAP] should come from your coverage tooling and must be accurate; stale coverage data will produce false retirement recommendations. Set [MAX_RETIREMENT_PERCENTAGE] conservatively (5-10% is a safe starting point) to prevent over-aggressive pruning. For regulated environments, populate [PRESERVED_TEST_IDS] with any tests mandated by compliance requirements before running the analysis. After receiving the output, execute the verification_steps before retiring any test—run the preserved tests in isolation to confirm coverage, review the coverage gaps with stakeholders, and stage retirements in a CI branch before merging to main.

This prompt is designed to be integrated into a scheduled or trigger-based analysis pipeline, not run as a one-off chat interaction. The typical integration point is a CI job that runs weekly or per-release, fetching test execution history, coverage data, and VCS blame information, then feeding a structured report into the prompt for analysis. The harness must collect and format the required inputs—test case metadata, historical failure/pass rates, associated coverage maps, and maintenance commit frequency—before invoking the model. Because the output recommends removing tests, the harness must treat every recommendation as a proposal, not an executable action, and route it through a human approval step before any test is retired or disabled.

The implementation should wrap the prompt in a validation layer that checks the structured output against a defined schema. Expect a JSON array of retirement candidates, each with fields like test_id, rationale_summary, cost_saving_estimate, and coverage_preservation_plan. The harness must validate that every test_id exists in the input suite, that cost_saving_estimate is a positive number, and that no two candidates share an identical coverage_preservation_plan if they cover the same requirement. On validation failure, retry once with the error message appended to the prompt context; if the retry also fails, log the raw output and flag the analysis run for human review. Use a model with strong JSON mode support (e.g., GPT-4o, Claude 3.5 Sonnet) and set temperature=0 to maximize deterministic, repeatable assessments across runs.

Logging and auditability are critical because this prompt influences what tests get removed from the regression suite. Store every analysis run as an immutable record: the full prompt input, the raw model output, the validated and parsed recommendations, and the final human decisions. This creates an evidence trail for compliance reviews and lets the team measure the prompt's precision over time. Wire the harness to a dashboard that tracks metrics like 'retirement candidates flagged per run,' 'human approval rate,' and 'post-removal defect escapes.' If the defect escape rate rises after retirements, the harness should automatically widen the prompt's [CONSTRAINTS] to require stronger coverage-preservation evidence before recommending removal. Start with a dry-run mode that only generates reports without applying changes for at least two analysis cycles to calibrate the team's trust in the recommendations.