Bug Report Test Case Generation Prompt for QA

This prompt is designed for QA engineers and CI/CD automation pipelines that need to convert a resolved bug report into a targeted, executable test suite. The core job-to-be-done is functional verification: confirming that the specific failure mode described in the bug no longer occurs and that the code changes did not introduce obvious regressions in adjacent functionality. The ideal user is a QA automation engineer or a developer practicing shift-left testing who already has a structured or semi-structured bug ticket containing clear reproduction steps, expected versus actual behavior, and environment details. The prompt assumes the bug has already been triaged, classified, and assigned for remediation—it is not a triage or root-cause analysis tool.

Use this prompt when you have a single, well-scoped bug report and need to generate test cases that can be immediately executed, either manually or as a blueprint for automated test scripts. The required inputs include the bug title, a detailed description, numbered reproduction steps, the observed incorrect behavior, the expected correct behavior, and any relevant environment configuration (OS, browser, version, device). The output is a test suite containing step-by-step instructions, explicit expected results for each step, and edge-case variations that probe the boundaries of the fix. This prompt is optimized for deterministic, functional defects—think null pointer exceptions, incorrect calculations, broken UI interactions, or API contract violations—rather than probabilistic or load-dependent issues.

Do not use this prompt for exploratory testing design, performance or load test planning, security penetration test generation, or usability evaluation. It will not produce useful output for bugs that lack clear reproduction steps or for systemic issues that require architectural refactoring. If the bug report is vague, incomplete, or still in triage, run it through a bug report completeness check or reproduction step extraction prompt first. For high-severity defects in regulated or safety-critical systems, always treat the generated test cases as a starting point that requires human review and augmentation before execution. The next step after reading this section is to prepare your structured bug input and review the prompt template to understand how placeholders map to your bug tracking fields.

This prompt template converts a bug report into a structured set of test cases for QA engineers. It takes the bug description, reproduction steps, and environment details as input and produces a JSON array of test cases, each with clear steps, expected results, and edge-case variations. The output is designed to be directly executable by a QA engineer or ingestible by a test management system.

codeCopy
You are a QA test design engineer. Given a bug report, generate a comprehensive set of test cases to verify the fix.

## INPUT
Bug Report:
[BUG_REPORT]

Reproduction Steps:
[REPRODUCTION_STEPS]

Environment:
[ENVIRONMENT_DETAILS]

## OUTPUT SCHEMA
Return a JSON object with a "test_cases" array. Each test case must have:
- "id": string, unique identifier (e.g., "TC-001")
- "title": string, short descriptive title
- "type": enum["happy_path", "edge_case", "regression", "negative"]
- "priority": enum["critical", "high", "medium", "low"]
- "steps": array of strings, ordered and atomic actions
- "expected_result": string, what should happen if the fix works
- "edge_case_variations": array of strings, alternative scenarios to test
- "linked_bug_id": string, reference to the original bug

## CONSTRAINTS
- Each step must be a single, testable action.
- Expected results must be falsifiable (pass/fail determinable).
- Include at least one test case that exactly reproduces the reported failure.
- Include at least two edge-case variations per test case.
- If the bug report lacks sufficient detail for a step, mark it with "[NEEDS CLARIFICATION]" instead of guessing.
- Do not invent environment details not present in the input.

## EXAMPLE
Input Bug: "Login button does nothing when clicked on mobile Chrome."
Output:
{
  "test_cases": [
    {
      "id": "TC-001",
      "title": "Verify login button triggers authentication on mobile Chrome",
      "type": "happy_path",
      "priority": "critical",
      "steps": [
        "Open the application in mobile Chrome on Android.",
        "Navigate to the login page.",
        "Enter valid credentials.",
        "Tap the login button."
      ],
      "expected_result": "User is authenticated and redirected to the dashboard.",
      "edge_case_variations": [
        "Tap login button rapidly multiple times.",
        "Tap login button while page is still loading assets."
      ],
      "linked_bug_id": "BUG-123"
    }
  ]
}

## RISK_LEVEL: [RISK_LEVEL]
If RISK_LEVEL is "high", add a "regression_risk_notes" field to each test case explaining what adjacent functionality might break.

To adapt this prompt, replace the square-bracket placeholders with real values before execution. [BUG_REPORT] should contain the full unstructured or structured bug description. [REPRODUCTION_STEPS] should be the numbered steps from the report, or an empty string if none were provided. [ENVIRONMENT_DETAILS] should include OS, browser, app version, and device information. [RISK_LEVEL] accepts "low", "medium", or "high" and controls whether regression risk notes are generated. If your test management system expects a different schema, modify the OUTPUT SCHEMA block accordingly, but keep the constraints on step atomicity and falsifiability. Always validate the output against the schema before ingesting it into your test pipeline.

The test case generation prompt is designed to be called programmatically from a QA automation service, a CI/CD pipeline, or an internal triage tool. The harness should treat the prompt as a stateless function: it receives a structured bug report as input and returns a set of test cases. The calling system is responsible for providing the bug context, managing the model request, validating the output, and deciding whether the generated tests are ready for a test run or require human review before execution.

Start by constructing the input payload. The [BUG_REPORT] placeholder expects a structured object containing at minimum a title, description, reproduction steps, expected versus actual results, and environment details. If your bug tracker stores these fields separately, assemble them into a single context block before calling the prompt. For model choice, a capable mid-tier model such as GPT-4o or Claude 3.5 Sonnet works well for this structured generation task. Set temperature low (0.0–0.2) to maximize determinism in test step ordering and expected-result phrasing. The output schema should be enforced either through the model's native structured output mode (e.g., response_format with a JSON schema) or by appending a strict [OUTPUT_SCHEMA] block to the prompt that defines the expected array of test case objects, each containing testId, title, preconditions, steps (ordered list), expectedResult, and edgeCaseVariations.

After receiving the model response, run a validation layer before the test cases enter any execution queue. Check that every generated test case includes at least one step that directly reproduces the reported failure mode—this is the minimum bar for usefulness. Validate schema compliance: every testId must be unique, every steps array must be non-empty, and edgeCaseVariations should not simply repeat the primary steps. Implement a retry policy for malformed outputs: if validation fails, re-invoke the prompt once with the same input and an added [CONSTRAINTS] note flagging the specific validation error. If the second attempt also fails, escalate to a human QA lead rather than silently dropping the output.

For high-severity bugs (S1/S2), route generated test cases to a manual review queue before they are added to a test run. The review interface should display the original bug report alongside the generated tests so a QA engineer can confirm coverage of the failure mode and adjust edge cases. For lower-severity bugs, you can auto-approve tests that pass schema validation and the failure-mode coverage check, but log the decision for audit. Store every generated test case with a trace back to the source bug report ID, the prompt version used, and the model identifier—this makes it possible to debug regressions in test generation quality when the prompt or model changes.

Avoid wiring this prompt directly into an automated test execution engine without a human-in-the-loop step for at least the first few dozen runs. Generated test steps may reference UI elements, API endpoints, or data fixtures that don't exist in your test environment. A dry-run validation that checks whether referenced resources are resolvable can catch many of these failures before they waste execution time. Over time, build a small golden dataset of bug-report-to-test-case pairs that your QA team has reviewed and approved; use this dataset to run regression evals whenever you modify the prompt or upgrade the model.