Negative Scenario Generation Prompt for Gherkin

This prompt is designed for test engineers and QA leads who need to systematically build unhappy-path coverage from existing happy-path Gherkin scenarios. The job-to-be-done is translating a set of positive behavior specifications into a comprehensive catalog of negative scenarios that exercise system boundaries, error handling, and failure modes. The ideal user has a set of validated happy-path .feature files and understands the system's architectural boundaries—APIs, databases, external dependencies, and authorization models—that are likely to fail. This is not a prompt for generating initial acceptance criteria from user stories; use the User Story to Gherkin Scenario Prompt Template for that upstream task.

Do not use this prompt when the happy-path scenarios themselves are ambiguous or incomplete. The quality of negative scenario generation depends entirely on the clarity of the positive cases and the explicit declaration of system constraints. If your happy-path scenarios contain vague steps like 'the system processes the request' without specifying what processing entails, the resulting negative scenarios will be equally vague and untestable. Similarly, avoid this prompt when you lack access to the system's technical boundaries—negative scenarios must map to specific failure points such as a particular API timeout, a database constraint violation, or an authorization check. Without this mapping, you will generate generic 'what if it fails' scenarios that add noise rather than coverage.

Before running this prompt, prepare three inputs: (1) a set of happy-path Gherkin scenarios with clear actors, actions, and expected outcomes; (2) a system boundary document listing external dependencies, data constraints, and authorization rules; and (3) a risk classification for each boundary (e.g., 'payment gateway timeout: high risk, requires human review'). After generation, validate that every negative scenario references a specific system constraint and produces a distinct, observable expected behavior. Scenarios that merely negate the happy path without a concrete failure mechanism should be discarded or rewritten. For high-risk domains like payments, healthcare, or access control, always route the generated scenarios through a human review step before adding them to your test suite.

This template takes a set of happy-path Gherkin scenarios and a system context description, then produces a corresponding set of negative scenarios. It forces the model to identify system boundaries, constraints, and failure modes before generating any output. The prompt is designed to be used inside an application pipeline where the output will be validated, versioned, and reviewed before merging into a test suite. Copy the block below, replace the square-bracket placeholders with your actual inputs, and wire it into your test generation workflow.

textCopy
You are a test design engineer specializing in negative-path coverage for behavior-driven development. Your task is to generate negative Gherkin scenarios from a set of happy-path acceptance criteria.

## INPUT
[HAPPY_PATH_GHERKIN]

## SYSTEM CONTEXT
[SYSTEM_CONTEXT]

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "boundary_analysis": [
    {
      "boundary_id": "string",
      "boundary_description": "string",
      "failure_modes": ["string"]
    }
  ],
  "negative_scenarios": [
    {
      "scenario_id": "string",
      "scenario_name": "string",
      "tags": ["string"],
      "mapped_boundary_id": "string",
      "mapped_happy_path_id": "string or null",
      "gherkin": "string"
    }
  ],
  "coverage_gaps": ["string"]
}

## INSTRUCTIONS
1. Parse the happy-path scenarios and identify every system boundary, external dependency, input constraint, authorization check, and resource limit implied or stated.
2. For each boundary, enumerate plausible failure modes: invalid inputs, missing inputs, unauthorized access, timeouts, resource exhaustion, dependency unavailability, and data corruption.
3. Generate at least one negative Gherkin scenario per boundary. Each scenario must include:
   - A descriptive Scenario name prefixed with "Negative:"
   - Tags for the failure category (e.g., @invalid-input, @unauthorized, @timeout, @resource-exhaustion)
   - A Given step that establishes the precondition and the specific boundary being tested
   - A When step that triggers the failure condition
   - A Then step that asserts the expected error behavior, error code, or degradation mode
4. Map every negative scenario to exactly one boundary from your analysis. If a scenario does not map to a specific boundary, do not include it.
5. If the happy-path scenarios reference external systems (APIs, databases, auth providers), generate scenarios for each dependency failure mode.
6. List any coverage gaps where the happy-path scenarios lack enough detail to generate confident negative tests.
7. Do not invent system behavior. If the happy-path scenarios or system context do not specify error handling, mark the scenario with @assumed-behavior and note the assumption.

## EXAMPLES
Example happy-path input:
Scenario: User creates an order with valid items
  Given the user is authenticated
  And the user has items in their cart
  When the user submits the order
  Then the order is created with status "confirmed"
  And the inventory is decremented

Example negative output:
{
  "boundary_analysis": [
    {
      "boundary_id": "auth-check",
      "boundary_description": "Authentication gate before order submission",
      "failure_modes": ["unauthenticated request", "expired token", "insufficient permissions"]
    }
  ],
  "negative_scenarios": [
    {
      "scenario_id": "neg-order-001",
      "scenario_name": "Negative: Unauthenticated user attempts order submission",
      "tags": ["@unauthorized", "@auth"],
      "mapped_boundary_id": "auth-check",
      "mapped_happy_path_id": null,
      "gherkin": "Scenario: Negative: Unauthenticated user attempts order submission\n  Given the user is not authenticated\n  When the user submits an order request\n  Then the response status is 401\n  And the response body contains an error code 'UNAUTHENTICATED'\n  And no order is created"
    }
  ],
  "coverage_gaps": []
}

## RISK LEVEL
[RISK_LEVEL]

If RISK_LEVEL is "high", every scenario tagged @assumed-behavior must include an explicit note that human review is required before the scenario is considered valid.

To adapt this template, start by replacing [HAPPY_PATH_GHERKIN] with the actual Gherkin text from your feature files. The [SYSTEM_CONTEXT] placeholder should contain a concise description of the system architecture, including external dependencies, authentication mechanisms, data stores, and known rate limits or quotas. For [CONSTRAINTS], specify any domain-specific rules that must not be violated, such as regulatory requirements, data residency rules, or maximum acceptable latency. Set [RISK_LEVEL] to "high" when the system under test handles payments, personal data, health information, or safety-critical operations; this activates the human-review requirement for assumed behaviors. After generating output, validate that every scenario in the negative_scenarios array has a non-empty mapped_boundary_id that matches an entry in boundary_analysis. If the model produces scenarios without clear boundary mappings, reject the output and retry with more explicit system context. The coverage_gaps field is your signal to go back to the requirements author and request more detail before the negative test suite can be considered complete.

This prompt is designed to be called programmatically as part of a test generation pipeline, not as a one-off chat interaction. The typical integration point is after a set of happy-path Gherkin scenarios has been approved. A test management system or CI job sends the happy-path scenarios as [INPUT] along with a [SYSTEM_BOUNDARY] description (e.g., 'REST API /orders', 'database write path', 'third-party payment webhook') and a [CONSTRAINT_LIST] derived from the system's non-functional requirements. The prompt returns a structured list of negative scenarios, each with a Gherkin body and a boundary_mapping field that ties it to a specific constraint. Your application should parse this output and insert each scenario into your test case management tool with a tag linking it to the originating happy-path scenario for traceability.

Validation is critical because a malformed Gherkin scenario can break downstream automation. Implement a post-processing validator that checks: (1) every scenario has a Scenario: keyword, (2) every step begins with Given, When, or Then, (3) the boundary_mapping field references a constraint present in the submitted [CONSTRAINT_LIST], and (4) no scenario duplicates a step sequence already present in the happy-path input. If validation fails, use a retry loop with a maximum of 2 additional attempts, feeding the specific validation errors back into the prompt's [PREVIOUS_OUTPUT] and [VALIDATION_ERRORS] placeholders. Log every validation failure and the final accepted output for auditability. For model choice, a mid-tier model like claude-3-5-sonnet or gpt-4o provides sufficient reasoning for constraint mapping without excessive latency; avoid smaller, faster models that may hallucinate Gherkin syntax under the structured output requirements.

Do not send this prompt's output directly to an automated test execution environment without human review if the system under test handles safety-critical functions, financial transactions, or personally identifiable information. In those contexts, route the generated scenarios to a QA lead for approval before they enter the automation suite. For lower-risk systems, you can auto-approve scenarios where the boundary_mapping confidence score (if you add one to the output schema) exceeds a threshold, and flag the rest for review. The primary failure mode in production is the model generating scenarios that are syntactically valid but semantically nonsensical—for example, testing a 'negative account balance' on a read-only endpoint. Your validator should also check that the action described in the When step is actually possible given the system boundary; a simple allowlist of valid operations per boundary can catch many of these errors before they waste engineering time.