Redundant Test Case Identification Prompt Template

This prompt is built for test architects and SDETs who need to analyze a test suite and identify functionally duplicate test cases. It is designed for workflows where test asset health is degrading due to copy-paste proliferation, uncoordinated test creation across teams, or missing review gates. Use this prompt when you have access to test case descriptions, steps, assertions, and coverage tags. The prompt produces a structured redundancy report with similarity scores, shared coverage paths, and specific merge or retire recommendations.

The ideal input includes test case metadata (ID, title, description, steps, expected results, tags, and coverage markers) for a set of candidate tests you suspect may overlap. The prompt works best when you provide 5–50 test cases at a time, grouped by functional area or feature. It is not a general code review tool and should not be used to compare implementation code. The output is designed to feed into a human review queue before any test is removed from the suite—this prompt recommends, it does not decide.

Do not use this prompt when you lack coverage tags or traceability links, when the test cases are purely exploratory session notes without structured steps, or when you need to compare performance test scripts or security test payloads where functional similarity is not the right lens. For those cases, use the Overlapping Test Coverage Analysis Prompt or the Test Case Similarity Clustering Prompt instead. Always validate the output against your test management system's traceability data before acting on any retirement recommendation.

The following prompt template is designed to be copied directly into your AI system or test analysis harness. It instructs the model to act as a test architect, comparing test cases from a provided suite to detect functional duplication. The prompt uses square-bracket placeholders—such as [TEST_SUITE_INPUT] and [SIMILARITY_THRESHOLD]—that you must replace with your actual test case data and configuration before execution. The output is a structured redundancy report with similarity scores, shared coverage paths, and actionable merge or retire recommendations.

textCopy
You are a test architect analyzing a test suite for redundant test cases. Your task is to identify functionally duplicate tests—cases that exercise the same code paths, assert the same behaviors, and would catch the same defects.

## INPUT
[TEST_SUITE_INPUT]

## CONSTRAINTS
- Consider two tests redundant if they share at least [SIMILARITY_THRESHOLD]% functional overlap in setup, execution steps, and assertions.
- Do not flag tests as redundant if they appear similar but exercise distinct risk areas, different boundary conditions, or separate security/auth contexts.
- For each redundancy finding, you must cite the specific shared coverage paths and assertions that justify the similarity score.
- If a test is a strict subset of another (all its assertions are covered by a larger test), flag it for retirement, not merge.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "redundancy_report": {
    "summary": {
      "total_tests_analyzed": <integer>,
      "redundant_groups_found": <integer>,
      "tests_recommended_for_retirement": <integer>,
      "tests_recommended_for_merge": <integer>,
      "estimated_coverage_preserved_percent": <float>
    },
    "redundant_groups": [
      {
        "group_id": <string>,
        "similarity_score": <float between 0 and 1>,
        "shared_coverage_paths": [<string>],
        "shared_assertions": [<string>],
        "test_cases": [
          {
            "test_id": <string>,
            "test_name": <string>,
            "recommendation": "retire" | "merge" | "keep",
            "rationale": <string explaining why this action preserves coverage while reducing redundancy>
          }
        ],
        "merge_suggestion": <string or null, describing how to combine tests if merge is recommended>,
        "risk_note": <string describing any coverage risk if these tests are consolidated>
      }
    ],
    "false_positive_notes": [
      {
        "test_ids": [<string>, <string>],
        "apparent_similarity": <string>,
        "why_not_redundant": <string describing the distinct risk area or condition each test covers>
      }
    ]
  }
}

## INSTRUCTIONS
1. Parse the input test suite and extract each test case's setup, execution steps, and assertions.
2. Group tests by functional area or feature under test.
3. Within each group, compare tests pairwise for functional overlap.
4. For each pair exceeding the similarity threshold, determine whether they are true duplicates or false positives.
5. For true duplicates, decide whether one test can be retired, or if both should be merged into a single consolidated test.
6. Produce the output JSON following the schema exactly. Do not include additional commentary outside the JSON.

## EXAMPLES
[EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

To adapt this template, replace [TEST_SUITE_INPUT] with your actual test case data—ideally structured as JSON or YAML containing test IDs, names, steps, and assertions. Set [SIMILARITY_THRESHOLD] to a value between 0.7 and 0.9 depending on how aggressively you want to surface candidates; start at 0.8 for most suites. The [EXAMPLES] placeholder should contain 2–3 annotated example pairs showing both true redundancy and a false positive where tests appear similar but cover distinct risks. Set [RISK_LEVEL] to "high" if the system under test is safety-critical or regulated, which will cause the model to apply stricter false-positive checks and require stronger evidence before recommending retirement. After generating the report, always run the eval checks described in the testing section of this playbook before acting on any retirement or merge recommendation.

This prompt is designed to operate as a batch analysis step within a test suite optimization workflow, not as a real-time chat interaction. The typical integration pattern involves pulling test case definitions, execution histories, and coverage maps from a test management system or CI pipeline, assembling them into the structured [TEST_CASE_LIST] input, and submitting the prompt through an API call. Because the output is a structured redundancy report, the harness must validate the JSON schema before any downstream action—retiring a test based on an unvalidated similarity score is a fast path to missing regressions.

The implementation should enforce a strict validation layer immediately after the model response. Validate that every redundancy_pair contains both test_case_a and test_case_b identifiers that exist in the input set, that similarity_score is a float between 0.0 and 1.0, and that shared_coverage_paths is a non-empty array of strings. Reject any recommendation where action is retire or merge but risk_areas_covered_by_remaining is empty—this indicates the model is proposing removal without confirming coverage preservation. On validation failure, retry once with an error message injected into the prompt context specifying which field failed and why. If the retry also fails, flag the pair for human review rather than silently dropping it.

Model choice matters here. Use a model with strong structured output support and a large context window, since [TEST_CASE_LIST] can grow large for mature suites. Enable JSON mode or structured outputs if the provider supports it, and supply the output schema as part of the API call rather than relying solely on the prompt's [OUTPUT_SCHEMA] description. For suites exceeding ~200 test cases, split the input into functional clusters using the test case similarity clustering prompt first, then run this redundancy prompt per cluster. Log every recommendation with the model version, input hash, and validation result so that audit trails exist for compliance-sensitive environments.

The human review gate is non-negotiable for any retire action. Even with perfect validation, a test that appears redundant by coverage data may guard against a regression the coverage model doesn't capture—an integration edge case, a production incident pattern, or an undocumented dependency. Route all retirement recommendations to a review queue with the original test bodies, the similarity justification, and the coverage overlap evidence. Only after explicit approval should a test be disabled or removed. Merge recommendations can be auto-accepted if the similarity score exceeds 0.95 and both tests have identical assertion sets, but still log the merge for post-commit review. Avoid wiring this prompt directly to a CI pipeline that auto-disables tests—the blast radius of a false positive is too high.