Bug Report Fix Verification Prompt Template

This prompt is for QA engineers and developers who need to confirm that a code change actually resolves a reported bug without introducing new failures. The job-to-be-done is turning a closed bug ticket and its associated fix into a structured, repeatable verification checklist. The ideal user has access to the original bug report, the fix description or pull request, and the environment where the fix can be tested. They are not guessing whether the fix works; they are systematically proving it against the original reproduction steps, regression risks, and edge conditions that the developer might not have considered.

Use this prompt when a bug fix has been implemented and is ready for verification, but before it merges to a production branch or ships to users. It is most effective when the original bug report contains clear reproduction steps, expected versus actual behavior, and environment details. The prompt assumes you can provide the fix description, the affected component, and any relevant test coverage gaps. Do not use this prompt for live incident triage, root cause analysis, or initial bug report structuring—those are separate workflows with their own playbooks. This prompt is also not a substitute for automated regression suites; it generates human-readable verification criteria that complement, not replace, existing test automation.

The output is a verification checklist where every criterion links back to the original bug report. Each item must be testable, specific, and traceable. The harness should validate that no checklist item duplicates another, that edge conditions are distinct from the primary reproduction path, and that regression checks reference specific related functionality. Before putting this into production, run the prompt against a golden set of verified bugs where you already know the correct checklist, and measure whether the generated criteria would have caught known regressions. If the prompt misses a regression that later occurred, that is a failure mode worth fixing before you trust it on live fixes.

This template converts a bug report and the corresponding fix description into a structured verification checklist. It forces the model to produce three categories of checks: reproduction confirmation (does the original bug no longer occur?), regression safety (did the fix break anything nearby?), and edge-case coverage (what boundary conditions should be tested?). Use this when you need a consistent, auditable verification plan that links every check back to the original report.

textCopy
You are a QA verification engineer. Given a bug report and a fix description, produce a verification checklist in strict JSON format.

[BUG_REPORT]

[FIX_DESCRIPTION]

[OUTPUT_SCHEMA]
{
  "verification_checklist": [
    {
      "id": "string (e.g., V-01)",
      "category": "reproduction_confirmation | regression_risk | edge_case",
      "check_description": "string (actionable test step or observation)",
      "expected_result": "string (what should happen if the fix works)",
      "linked_bug_symptom": "string (which part of the original report this check addresses)",
      "risk_if_skipped": "string (what could be missed)"
    }
  ],
  "coverage_gaps": ["string (any untested areas or assumptions)"],
  "minimum_environment_requirements": "string (OS, browser, version, or config needed to execute checks)"
}

[CONSTRAINTS]
- Every check must reference a specific symptom or detail from [BUG_REPORT].
- Include at least 2 checks per category unless the category is genuinely inapplicable; if so, explain why in coverage_gaps.
- Regression checks must name specific modules, functions, or components that the fix touched.
- Edge-case checks must include boundary values, null inputs, concurrency scenarios, or permission variations where relevant.
- Do not invent symptoms or risks not present in the inputs.
- If the fix description is insufficient to generate meaningful checks, output an empty checklist and explain the gaps in coverage_gaps.

[EXAMPLES]
Bug Report: "Users cannot submit the payment form when the cart total exceeds $999.99. The submit button remains disabled."
Fix Description: "Removed an incorrect max-value validator on the cart total field in PaymentForm.js."

Output:
{
  "verification_checklist": [
    {
      "id": "V-01",
      "category": "reproduction_confirmation",
      "check_description": "Add items to cart totaling $1,200.00 and attempt to submit the payment form.",
      "expected_result": "Submit button is enabled and payment processes successfully.",
      "linked_bug_symptom": "Submit button disabled when cart total exceeds $999.99.",
      "risk_if_skipped": "Original bug may still be present if the validator was not fully removed."
    },
    {
      "id": "V-02",
      "category": "regression_risk",
      "check_description": "Submit payment form with a negative cart total (e.g., -$50.00) if the UI allows it.",
      "expected_result": "Form validation rejects negative totals with a clear error message.",
      "linked_bug_symptom": "Validator removal in PaymentForm.js may have removed other guardrails.",
      "risk_if_skipped": "Removing the max-value validator could also remove min-value protection."
    },
    {
      "id": "V-03",
      "category": "edge_case",
      "check_description": "Submit payment form with cart total exactly $999.99.",
      "expected_result": "Submit button is enabled and payment processes successfully.",
      "linked_bug_symptom": "Boundary condition at the previously enforced limit.",
      "risk_if_skipped": "Off-by-one errors at the old threshold could persist."
    }
  ],
  "coverage_gaps": ["No concurrency test: multiple users submitting the same cart was not in scope."],
  "minimum_environment_requirements": "Staging environment with payment processor test mode enabled."
}

Adapt this template by replacing the example with your own domain-specific scenarios. If your bug reports follow a structured format, include that schema in [BUG_REPORT] so the model knows what fields to expect. For high-severity bugs, add a [RISK_LEVEL] parameter and adjust the minimum check count per category accordingly. The output schema is intentionally flat to simplify parsing in CI/CD pipelines; if you need nested structures for test automation frameworks, extend the schema but keep the category and linked_bug_symptom fields to maintain traceability.

Before wiring this into an automated pipeline, run it against a golden set of 10-20 historical bug-fix pairs where you already know the correct verification steps. Measure whether the generated checklist catches the known regression that would have occurred if the fix were incomplete. If the model skips a critical check, add a more specific constraint or an additional example showing that failure mode. For production use, always require a human QA lead to approve the checklist before it becomes the gate for fix deployment.

This prompt is designed to be called after a bug fix has been merged and a developer or QA engineer needs a structured verification plan. The harness should inject the original bug report as [BUG_REPORT] and the fix description or linked pull request summary as [FIX_DESCRIPTION]. The model returns a checklist in a predefined JSON schema, which the harness must validate before surfacing it to a human tester or an automated test runner. Because verification criteria directly impact release quality, the output should be treated as a draft requiring human approval before it becomes the official test plan.

The implementation should follow a validate → retry → escalate pattern. First, parse the model's JSON output and validate it against a strict schema that requires each checklist item to have a unique id, a criterion string, a category enum (e.g., reproduction, regression, edge_case), and a reference_to_original_report field that quotes or cites the relevant section of the bug report. If validation fails, retry once by appending the validation error to the prompt as a [PREVIOUS_ERROR] context block and re-requesting the corrected output. If the second attempt also fails, log the failure and route the task to a human QA lead for manual authoring. This prevents a malformed checklist from silently entering the test management system.

For logging and observability, record the prompt version, model used, input report ID, validation pass/fail status, and the final approved checklist. If your team uses a test case management tool like TestRail or Xray, map the verified JSON output to test case creation API calls. Each checklist item should be traceable back to the original bug report through the reference_to_original_report field, creating an audit trail that proves coverage. In high-risk domains such as financial software or healthcare systems, require a second human reviewer to sign off on the checklist before any automated test case creation occurs. Avoid using this prompt for cosmetic or low-severity bugs where a full verification checklist adds process overhead without proportional risk reduction.