Boundary Value Analysis Prompt for Behavior Specs

This prompt is for QA engineers and SDETs who need to translate numeric, date, string-length, and collection-size constraints from requirements into precise, testable Gherkin scenarios. The job-to-be-done is systematic boundary value analysis (BVA): identifying on-point, off-point, and extreme-value partitions for every constrained input field and producing executable scenarios with explicit expected outcomes. You should use this prompt when you have a requirement that specifies a range, limit, or size constraint—such as 'password must be 8–64 characters,' 'discount applies to orders over $100,' or 'report generation must complete within 30 seconds'—and you need to ensure your test suite covers the boundaries, not just the happy path. The ideal user has access to the source requirement text and understands the system's input validation rules, but may not have exhaustively mapped every boundary partition.

Do not use this prompt when the requirement lacks any quantifiable constraint, when you need performance test scenarios rather than functional boundary tests, or when the system under test has undocumented validation behavior that requires exploratory investigation first. This prompt assumes the constraints are explicitly stated or can be reasonably inferred from the specification. It is not a replacement for state-transition testing, authorization matrix coverage, or concurrency test design—those require separate, specialized prompts. If the requirement involves complex cross-field validation rules (e.g., 'end date must be after start date'), pair this prompt with the Data Validation Rule to Gherkin prompt to ensure relational constraints are covered alongside field-level boundaries.

Before running this prompt, gather the requirement text, any referenced schema definitions, and the expected error-handling behavior for out-of-bounds inputs. The prompt works best when you provide the constraint type (numeric, date, string-length, or collection-size) explicitly, as this guides the partition logic. After generating the scenarios, validate that every boundary has both an on-point value (the exact boundary) and an off-point value (just outside the boundary), and that extreme values like zero, empty, maximum, and overflow are represented. If the system's error messages or HTTP status codes are known, include them in the expected outcomes to make the scenarios automation-ready. For high-risk domains like payments or healthcare, always route the generated scenarios through a peer review step before committing them to your test management system.

This prompt template is the core of the Boundary Value Analysis playbook. It is designed to take a structured description of a system constraint—such as a field length, a numeric range, or a date window—and produce a set of Gherkin scenarios that test the boundaries of that constraint. The template uses square-bracket placeholders for all variable inputs, making it straightforward to copy, adapt, and integrate into a test generation pipeline. The output is structured to be directly usable by BDD frameworks like Cucumber or SpecFlow.

markdownCopy
You are a QA engineer specializing in boundary value analysis for behavior-driven development.

Your task is to analyze the provided constraint and generate a set of Gherkin scenarios that test its boundaries. You must produce scenarios for on-point (valid boundary), off-point (just outside the boundary), and extreme values.

**Constraint to Analyze:**
[CONSTRAINT_DESCRIPTION]

**Output Schema:**
Generate a Gherkin feature file section with the following structure:
- A `Feature` title summarizing the boundary test.
- A `Scenario Outline` for each boundary condition (minimum, maximum, and any other relevant partition).
- Each `Scenario Outline` must include an `Examples` table with columns for the test input and the expected result.
- Use tags like `@boundary`, `@on-point`, `@off-point`, and `@extreme` to categorize each scenario.

**Constraints for Generation:**
- [OUTPUT_SCHEMA]: The output must be valid Gherkin syntax.
- [CONSTRAINTS]: Do not invent constraints. Only test the boundaries explicitly described in [CONSTRAINT_DESCRIPTION]. If the constraint is a numeric range of 1-100, test values like 0, 1, 100, 101, and a mid-range value. For string lengths, test empty strings, max length, max length + 1, and a string with special characters.
- [RISK_LEVEL]: Medium. The output will be used to guide automated test creation, so precision is critical. If the constraint description is ambiguous, state the assumption you are making before generating the scenarios.

**Example Input:**
[CONSTRAINT_DESCRIPTION]: "The 'age' field must be an integer between 18 and 65, inclusive."

**Example Output:**
```gherkin
Feature: Age Field Boundary Validation
  As a user, I should be prevented from entering an age outside the 18-65 range.

  @boundary @off-point
  Scenario Outline: Age is below the minimum valid value
    Given I enter an age of "<age>"
    When I submit the form
    Then I should see an error message "Age must be between 18 and 65"
    Examples:
      | age |
      | 17  |
      | 0   |
      | -1  |

  @boundary @on-point
  Scenario Outline: Age is at the minimum valid value
    Given I enter an age of "<age>"
    When I submit the form
    Then the submission should be successful
    Examples:
      | age |
      | 18  |

  # ... other scenarios for maximum, on-point, and extreme values

Now, generate the boundary value analysis Gherkin scenarios for the provided constraint.

To adapt this template, replace the [CONSTRAINT_DESCRIPTION] placeholder with a clear, single-sentence description of the rule you are testing. The [OUTPUT_SCHEMA] and [CONSTRAINTS] placeholders can be customized to enforce specific formats or to add domain-specific rules, such as requiring specific error codes or log messages in the Then steps. For high-risk financial or healthcare applications, always add a human review step after generation to verify that no boundary conditions were missed and that the expected outcomes align with the precise regulatory specification.

The Boundary Value Analysis 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 a QA microservice or a CI job that receives a structured requirement object (containing fields, constraints, and data types) and returns a set of Gherkin scenarios. You should wrap the prompt in an application harness that validates the output schema before the scenarios ever reach your test management system. The harness is responsible for providing the [INPUT_SCHEMA] and [CONSTRAINTS] placeholders from a machine-readable source such as a JSON Schema definition, an OpenAPI spec fragment, or a structured requirement ticket. Do not rely on free-text requirements alone; the prompt performs best when it receives explicit type information (e.g., type: integer, minimum: 0, maximum: 100, exclusiveMaximum: true) rather than prose descriptions of limits.

The implementation harness must enforce a strict output contract. After the model responds, validate that every returned scenario conforms to the expected Gherkin structure and that each boundary partition (on-point, off-point, extreme-value) is present for every numeric, date, string-length, or collection-size constraint in the input. A recommended approach is to define a JSON output schema in the prompt itself using the [OUTPUT_SCHEMA] placeholder, then validate the parsed response with a library like ajv (JavaScript) or pydantic (Python). If validation fails, implement a single retry by feeding the validation error message back into the prompt via a [CORRECTION_FEEDBACK] placeholder. After one retry, if the output still fails schema validation, route the result to a human review queue rather than silently dropping malformed scenarios. Log every generation attempt—including the input constraints, the raw model output, and the validation result—so that prompt drift and model behavior changes are traceable over time.

For CI pipeline integration, treat the prompt as a test asset under version control. Store the prompt template alongside your test generation code, and use a model that supports structured outputs (such as GPT-4o with response_format or Claude with tool-use mode) to reduce parsing fragility. When wiring into a test management system like TestRail, Xray, or Zephyr, map the generated Gherkin scenarios to the system's API: each scenario becomes a test case with the boundary type (on-point, off-point, extreme) stored as a tag or custom field for coverage reporting. Add an eval step that compares the generated boundary partitions against a known-good set of expected partitions for a small golden dataset; if the model misses a partition class (e.g., no extreme-value scenario for a date field), fail the CI job. This ensures that prompt changes don't silently degrade boundary coverage. Finally, never auto-commit generated scenarios to the test repository without human approval when the input constraints come from a regulated domain (safety-critical, financial, or healthcare systems). The harness should flag these for review and attach the full generation trace to the review request.