Edge Case Discovery Prompt for Acceptance Criteria

This prompt is for QA leads and test architects who need to move beyond happy-path acceptance criteria and systematically discover edge cases, boundary conditions, and error states from a feature specification. The job-to-be-done is translating a product requirement or user story into a prioritized, actionable catalog of edge cases that can be immediately converted into Gherkin scenarios or automated test scripts. The ideal user has a written feature specification—even a rough one—and needs to ensure the test plan covers null inputs, timeouts, concurrency races, malformed payloads, and resource exhaustion before development begins.

Use this prompt when you have a stable-enough feature spec and need to front-load quality by identifying failure modes early. It is particularly effective during sprint planning, refinement sessions, or test plan reviews where the team is asking 'what could go wrong?' The prompt requires a [FEATURE_SPECIFICATION] input that describes the intended behavior, actors, system boundaries, and any known constraints. You should also provide a [FAILURE_CATEGORIES] list to guide the model toward the types of edge cases that matter for your domain—such as authentication bypass, data validation edge cases, or third-party dependency failures. Do not use this prompt when the specification is still in flux or when you need creative brainstorming rather than structured, coverage-aware analysis. It is not a replacement for exploratory testing; it is a systematic discovery tool that complements human intuition.

The output is a prioritized edge case catalog, not a final test suite. Each edge case includes preconditions, expected behavior, and a Gherkin-ready scenario outline, but you will still need to review the results for relevance, fill in implementation-specific details, and validate that the model did not hallucinate system behaviors not described in the specification. For high-risk domains—such as financial transactions, healthcare data handling, or access control—always require human review of the generated edge cases before they enter your test management system. The next step after using this prompt is to feed the discovered edge cases into your Gherkin scenario generation workflow and your test automation framework.

The following prompt template is designed to be copied directly into your AI harness, notebook, or prompt management system. It accepts a feature specification and produces a prioritized catalog of edge cases, boundary conditions, and failure modes. Each placeholder in square brackets must be replaced with concrete values before execution. The template assumes you have a feature specification ready and want structured, testable edge cases rather than freeform brainstorming.

textCopy
You are a QA architect specializing in edge case discovery. Your task is to analyze a feature specification and produce a comprehensive, prioritized catalog of edge cases, boundary conditions, error states, and unexpected input scenarios.

## INPUT
Feature Specification:
[FEATURE_SPECIFICATION]

Additional Context (optional):
[ADDITIONAL_CONTEXT]

## CONSTRAINTS
- Risk Level: [RISK_LEVEL] (choose: low, medium, high, critical)
- Target Test Layer: [TEST_LAYER] (choose: unit, integration, end-to-end, all)
- Maximum Edge Cases: [MAX_EDGE_CASES]
- Required Coverage Categories: [COVERAGE_CATEGORIES] (e.g., null inputs, timeouts, concurrency, authorization, data validation, dependency failure)

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "feature_summary": "One-sentence summary of the feature under analysis",
  "coverage_categories_analyzed": ["category1", "category2"],
  "edge_cases": [
    {
      "id": "EC-001",
      "category": "boundary_value | error_state | concurrency | authorization | null_handling | timeout | data_validation | dependency_failure | state_transition | other",
      "priority": "critical | high | medium | low",
      "title": "Short descriptive title",
      "preconditions": "System state and inputs required to trigger this edge case",
      "trigger": "Specific action, input, or condition that activates the edge case",
      "expected_behavior": "What the system should do when this edge case occurs",
      "failure_impact": "What happens if this edge case is not handled correctly",
      "gherkin_outline": "Given [precondition] When [trigger] Then [expected outcome]",
      "test_layer": "unit | integration | e2e",
      "related_requirements": ["Reference to spec section or requirement ID"]
    }
  ],
  "coverage_gaps": ["Categories or scenarios not covered by the specification"],
  "recommended_test_approach": "Brief guidance on how to prioritize and execute these edge cases"
}

## INSTRUCTIONS
1. Read the feature specification carefully. Identify all system boundaries, external dependencies, user inputs, and state changes.
2. For each coverage category listed in [COVERAGE_CATEGORIES], generate at least one edge case if applicable.
3. Prioritize edge cases by: (a) likelihood of occurrence, (b) severity of failure impact, (c) detectability in testing.
4. Ensure every edge case has a clear, executable Gherkin outline.
5. Flag any coverage gaps where the specification is silent on behavior that should be defined.
6. If [RISK_LEVEL] is "critical" or "high", include additional scrutiny on security, data integrity, and availability edge cases.
7. Do not invent requirements. Base all edge cases on the provided specification and reasonable inferences from common failure patterns in [TEST_LAYER] testing.

## EXAMPLES
Example edge case for a login feature:
{
  "id": "EC-001",
  "category": "concurrency",
  "priority": "high",
  "title": "Simultaneous login attempts from same account",
  "preconditions": "User account exists with valid credentials. No active session.",
  "trigger": "Two login requests with correct credentials arrive within 100ms of each other",
  "expected_behavior": "Both requests succeed or one succeeds and the other receives a session-conflict error. No duplicate sessions created.",
  "failure_impact": "Duplicate sessions may cause data corruption, inconsistent state, or security audit failures.",
  "gherkin_outline": "Given a user account with no active session When two valid login requests arrive simultaneously Then exactly one session is created and the second request receives a clear error",
  "test_layer": "integration",
  "related_requirements": ["REQ-AUTH-003", "REQ-SESSION-001"]
}

To adapt this template, replace each placeholder with values specific to your feature and testing context. For [COVERAGE_CATEGORIES], select from the list provided or add domain-specific categories such as "rate limiting," "data residency," or "accessibility." If you do not have a [MAX_EDGE_CASES] limit, set it to a reasonable number like 20 to keep the output focused. The [RISK_LEVEL] placeholder controls how aggressively the prompt searches for severe failure modes—use "critical" for payment systems, authentication, or data deletion features. After generating edge cases, validate the output against your specification to ensure no fabricated requirements were introduced. For high-risk features, always have a human QA lead review the edge case catalog before committing it to your test plan.

This prompt is designed to be called programmatically as part of a feature review workflow, not as a one-off chat interaction. The application layer should supply the feature specification, known constraints, and a risk profile. The model returns a structured JSON catalog of edge cases, each with a priority, precondition, expected behavior, and a Gherkin-ready scenario outline. The primary integration point is after a feature spec is drafted but before test case authoring begins, ensuring that boundary conditions and failure modes are explicitly documented.

To wire this into an application, construct a request that injects the [FEATURE_SPECIFICATION], [KNOWN_CONSTRAINTS], and [RISK_PROFILE] into the prompt template. The [OUTPUT_SCHEMA] placeholder should be replaced with a strict JSON schema definition that your application can validate. After receiving the model response, run a structural validator to confirm every edge case object has the required fields (id, priority, category, precondition, expected_behavior, gherkin_outline). If validation fails, implement a retry loop (maximum 2 retries) that feeds the validation errors back into the prompt as additional context. For high-risk domains such as payments or access control, route any edge cases marked priority: critical to a human review queue before they are accepted into the test plan.

Choose a model with strong structured output capabilities and a context window large enough to hold the full specification plus the output schema. GPT-4o or Claude 3.5 Sonnet are suitable defaults. Log every prompt version, input hash, and output for auditability. The most common production failure mode is the model omitting entire failure categories (e.g., concurrency or timeout scenarios). Mitigate this by including a [COVERAGE_CHECKLIST] in the prompt that explicitly lists required categories, and add a post-processing step that flags any missing categories for manual review. Do not use this prompt for safety-critical systems without a human-in-the-loop approval step on the final edge case catalog.