Test Suite Consolidation Planning Prompt

This prompt is designed for test architects and SDETs who have already completed a rigorous analysis of their test suite and now need to produce a sequenced, defensible execution plan. The primary job-to-be-done is translating analysis outputs—such as redundancy reports, coverage overlap matrices, risk assessments, and retirement justifications—into a phased consolidation roadmap. The ideal user has hard evidence about which tests are candidates for merging, retiring, or refactoring, and needs a stakeholder-ready plan that sequences the work to minimize regression risk while maintaining clear coverage gates.

Use this prompt when you need to produce a document that multiple stakeholders can review, approve, and execute against. The output should include per-phase coverage targets, explicit risk gates that must be satisfied before proceeding to the next phase, stakeholder approval checkpoints, and rollback triggers if coverage regresses during consolidation. The prompt assumes you can provide structured inputs: a list of candidate tests with their recommended actions (merge, retire, refactor), the current coverage map, risk criticality scores, and any dependency chains between test cases. Without these inputs, the model will generate a speculative plan that is unsuitable for production decisions.

Do not use this prompt as a substitute for the underlying analysis. If you feed it a raw list of test names without supporting evidence, similarity scores, or coverage impact assessments, the output will lack the rigor required for real test suite changes. This prompt also should not be used for initial test case design, flaky test debugging, or performance test planning—those are separate workflows with their own playbooks. The consolidation plan this prompt produces is a coordination artifact, not a replacement for the technical analysis that justifies each retirement or merge decision. Before executing any phase, validate the plan against your current CI pipeline state and ensure rollback mechanisms are in place.

This prompt template is designed to be pasted directly into your AI harness. It instructs the model to act as a test architect and produce a sequenced consolidation roadmap. Before execution, replace every square-bracket placeholder with the specific analysis data from your test suite. The prompt is structured to enforce a strict output schema, making the response machine-readable for downstream tooling or stakeholder review dashboards.

textCopy
SYSTEM: You are a senior test architect specializing in large-scale test suite optimization. Your task is to produce a phased consolidation plan based on the provided analysis data. Your recommendations must be defensible, risk-aware, and auditable. Do not recommend retiring a test unless you can justify it with coverage overlap data or obsolescence evidence. Every phase must include explicit rollback triggers if coverage regresses.

USER:
Generate a Test Suite Consolidation Plan using the following inputs:

[TEST_SUITE_ANALYSIS_REPORT]
[COVERAGE_OVERLAP_MATRIX]
[OBSOLESCENCE_ASSESSMENT]
[RISK_ASSESSMENT_REGISTER]
[STAKEHOLDER_LIST]

OUTPUT_SCHEMA:
{
  "plan_name": "string",
  "executive_summary": "string (max 150 words)",
  "phases": [
    {
      "phase_id": "integer",
      "objective": "string",
      "actions": [
        {
          "action_type": "MERGE | RETIRE | REFACTOR | DEFER",
          "target_test_ids": ["string"],
          "justification": "string (cite specific data from the analysis report)",
          "coverage_impact": {
            "risk_area": "string",
            "before_coverage_pct": "number",
            "after_coverage_pct": "number",
            "gap_introduced": "boolean"
          },
          "rollback_trigger": "string (specific metric threshold that would reverse this action)"
        }
      ],
      "approval_gate": {
        "required_approvers": ["string (from STAKEHOLDER_LIST)"],
        "acceptance_criteria": ["string"]
      },
      "estimated_effort_hours": "number"
    }
  ],
  "global_rollback_conditions": ["string"],
  "risk_register_updates": ["string"]
}

CONSTRAINTS:
- Do not propose retiring a test if it is the sole coverage for a high-risk area identified in the RISK_ASSESSMENT_REGISTER.
- If a test is flaky but covers a unique path, classify it as REFACTOR, not RETIRE.
- Every MERGE action must specify the resulting single test that replaces the merged set.
- The plan must be sequenced so that no phase depends on a test that is retired in a prior phase.

After pasting this template, verify that your placeholders contain structured data, not raw logs. The COVERAGE_OVERLAP_MATRIX should be a machine-readable mapping of test IDs to covered requirements, and the OBSOLESCENCE_ASSESSMENT should link each candidate test to a specific dead code path or deprecated feature. If your analysis data is still in narrative form, run a pre-processing step to extract structured records before populating this prompt. The output JSON can be fed directly into a test management system or a stakeholder review dashboard. Always run a schema validation on the model's response before presenting it to approvers, and flag any phase where the after_coverage_pct drops below your organization's risk threshold for human review.

The Test Suite Consolidation Planning Prompt is not a one-shot query. It is a planning engine that should be embedded in a pipeline where inputs are programmatically assembled from live test management systems, coverage databases, and risk registers. Before calling the model, gather the current test inventory with metadata (last execution date, pass/fail history, linked requirements), a coverage map showing which tests cover which features, and a risk register that ranks features by business criticality. Assemble these into the [TEST_INVENTORY], [COVERAGE_MAP], and [RISK_REGISTER] placeholders. The [CONSTRAINTS] block should be populated from organizational policy: maximum phases, mandatory approval checkpoints, and any tests that are locked from retirement due to compliance requirements.

After the model returns a phased consolidation plan, validate the output against a structural schema before any human sees it. Each phase must contain a list of test IDs to merge, retire, or refactor; a coverage target percentage; a risk gate condition; and a rollback trigger. Use a JSON Schema validator to confirm these fields exist and that no test ID appears in conflicting actions across phases. If validation fails, retry the prompt once with the validation errors injected into the [CONSTRAINTS] block as explicit correction instructions. If the second attempt also fails, route the raw output to a human reviewer with the validation errors highlighted rather than retrying indefinitely.

Coverage regression is the primary failure mode. After the model proposes a retirement or merge action, run a coverage impact simulation: for each test marked for removal, check whether any requirement or risk item would lose all its covering tests. If so, flag that action as blocked and feed it back to the model as a constraint violation. This check should happen in application code, not in the prompt, because the model can hallucinate coverage relationships. Log every consolidation recommendation alongside the coverage simulation result, the validator pass/fail status, and the final disposition (accepted, modified, rejected) for auditability.

Human review gates are mandatory for any phase that retires more than a configurable threshold of tests or touches features above a criticality score defined in the risk register. The review interface should display the model's rationale, the coverage simulation results, and a diff of what coverage changes. Stakeholders approve or reject per phase, not per individual test, to keep the workflow manageable. Approved phases should be written back to the test management system as tickets or tags, not executed automatically. Rejected phases should trigger a prompt retry with the rejection reason appended to [CONSTRAINTS].

Model choice matters here. Use a model with strong reasoning and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, because the consolidation logic requires multi-step trade-off reasoning across coverage, risk, and maintenance cost. Avoid small or local models for the planning step itself, though they can be used for downstream tasks like generating individual test refactoring scripts. Set temperature to 0 or very low to maximize deterministic, reviewable outputs. If the suite is large, split the inventory by functional area and run the prompt per area, then merge the plans with a deduplication pass that catches cross-area conflicts.