ChatGPT can help inspect supplied requirements and draft technical material, as described in the official OpenAI documentation. Treat the resulting cases as proposals to review against your specification. A well-written expected result is not evidence that the application produced it.
Start with a rule small enough to inspect
This original fictional reservation feature has these supplied rules:
- A Draft reservation accepts an integer quantity from 1 through 5, inclusive.
- Confirming a Draft with a valid quantity changes its state to Confirmed and records that quantity.
- A quantity outside the accepted range is rejected; the reservation remains Draft.
- A Confirmed reservation's quantity cannot be edited through this operation.
No behavior is supplied for blank input, decimal text, repeated confirmation, cancellation, or two people editing at once. Keep those questions visible. Do not let a model decide that blank means one merely because that would simplify a test.
Choose values around each boundary
For the integer range, use 0, 1, 5, and 6. They check just below the lower bound, the lower bound, the upper bound, and just above it. Include an interior value such as 3 if useful for the normal flow, but do not substitute it for both boundaries.
| Case | Starting state and input | Action | Expected result from supplied rule |
|---|---|---|---|
| T01 | Draft; quantity 0 | Confirm | Rejected; remains Draft |
| T02 | Draft; quantity 1 | Confirm | Confirmed; records 1 |
| T03 | Draft; quantity 5 | Confirm | Confirmed; records 5 |
| T04 | Draft; quantity 6 | Confirm | Rejected; remains Draft |
| T05 | Confirmed with 3; proposed quantity 4 | Edit quantity through this operation | Edit refused; state and recorded quantity remain Confirmed/3 |
| Q01 | Draft; blank quantity | Confirm | Specification question; no executable expected result agreed |
Give every executable case its own clean fixture. If T02 leaves a shared reservation Confirmed, running T03 against that same record would test the wrong starting state. Record the setup and reset procedure with the case.
T05 needs more than a disabled-looking input. The relevant outcome is that the operation refuses the edit and preserves the stored quantity. The tester needs an authorized way to inspect that result in the actual test environment.
Separate specification gaps from failures
Q01 is not a failed application test. It has no agreed expected behavior. Ask the product owner what blank input should do, record the decision with its rule reference, then create a case.
For T01 through T05, execution starts as Not run. After an actual attempt, record the build, environment, fixture ID, observed result, and evidence. A difference between expected and observed behavior can then be investigated. Do not copy the expected column into an “actual” column to make the table look complete.
The user acceptance testing guide covers the broader question of whether a complete user workflow achieves its agreed business outcome. These smaller rule and state cases help isolate behavior before that acceptance review; passing them would not establish overall acceptance.
Copy a requirements-to-cases prompt
Draft reviewable test cases from this exact feature specification.
Specification/version and rule IDs: [PASTE]
States, allowed transitions, and input constraints: [PASTE]
Test environment and available fixture/reset method: [ENTER]
Known unresolved behavior: [LIST]
First identify contradictory or missing requirements. Do not resolve
them by guessing common UI behavior. Separate questions from executable
cases. For each executable case include ID, rule reference, purpose,
clean starting state, concrete inputs, action, expected state/data,
and the source wording supporting the expectation.
Cover integer range boundaries and allowed/forbidden state transitions
where relevant. Avoid cases differing only by a cosmetic input value.
Keep observed results empty and execution status Not run. Do not claim
coverage completeness or a passed application test. Return the smallest
useful review set before proposing automation. Do not modify software.
Review the expected result with the person who owns the rule
Walk T02, T03, and T05 together. Confirm that both endpoints are included and that the edit restriction concerns this operation after confirmation. Resolve Q01 without changing the meaning of already agreed rules.
Only then translate the cases into the team's chosen test tool. Keep fixture setup and post-action state checks in that translation. Record actual results after running the tests against the named build, and retain unresolved cases as questions rather than silently deleting them.