📋 Test Case Generation

Test Case Generation: Claude generating test cases from an incomplete user story is like a contractor building from a floor plan missing dimensions — the mechanism is exact: the

Claude generating test cases from an incomplete user story is like a contractor building from a floor plan missing dimensions — the mechanism is exact: the contractor CAN guess a wall's length (a statistically plausible number), but the building might not fit the lot. Here is the question worth sitting with: if Claude can generate 20 test cases in seconds, why should the FIRST thing you ask it to do be to list what's missing, not to write the tests? Because most user stories are silent on edge cases and thresholds — skip asking for the gaps, and Claude fills them with its own trained-in defaults, not your product's actual rule. Java comparison: this is like writing a JUnit test against an interface method with no Javadoc — you can compile a guess, but without the contract's real pre/postconditions you are testing your assumption, not the requirement. The QA stake: a test suite built on Claude's silently-filled assumptions passes in CI yet misses the real acceptance criterion — the same fake-confidence trap from the Intro tab's oracle problem, this time at the story-intake stage rather than the test-design stage.

Ask Before You Generate

Use a two-step technique instead of asking for tests directly. Step one: paste the user story and acceptance criteria, and ask Claude to LIST every rule that is ambiguous or missing — do not request any test yet. Step two: take that list to your product owner or team and get real, confirmed answers. Only then do you ask for test cases, explicitly instructing Claude to use ONLY the confirmed rules. This ordering turns a one-shot generation into a controlled, two-phase conversation where the oracle gap surfaces before it can be silently filled.

Reasoning: why generate in Gherkin specifically, rather than a plain bullet list? Given/When/Then forces an explicit precondition, action and expected-result triple for every scenario, which happens to be exactly the shape Claude needs filled to avoid vague output — the format itself becomes a forcing function for specificity, the same way a strongly-typed method signature forces you to supply every parameter before the code compiles.

Reuse the 4 ingredients you learned in the Prompt Lab on the Prompt Engineering tab: role = "senior QA engineer", context = user story + acceptance criteria, format = "Gherkin", constraint = "base it only on confirmed rules".

Step by Step: From User Story to Gherkin

The user story and acceptance criteria are pasted into the prompt as context.

Before writing any test, Claude is asked to list every rule in the story that is unclear or missing.

Resolve with your team

Real ambiguities are resolved with the PO/team — not with an assumption Claude invented.

N Given/When/Then scenarios are requested, based ONLY on the confirmed rules.

Review as the oracle

Each scenario is checked by YOU against the acceptance criteria checklist — fluent Gherkin syntax is not proof that the coverage is correct.

Arrange the flow for generating reliable Gherkin scenarios from a user story in the correct order.