Software projects
Derive test cases from a feature requirement
Break a requirement into one behavior per test case, each with a setup, an action, an expected result and a way to record evidence. Then add the boundaries and failure paths the requirement implies but does not state, before anyone approves the build.
A text to start with
Here is a feature requirement: [paste requirement]. The users are [user types] and the inputs are [inputs and limits]. List test cases with setup, action, expected result and the evidence I should capture. Include normal use, boundary values, invalid input and what should happen when something goes wrong. Flag any place where the requirement is too vague to write an expected result.
Example request. Change the details to fit your situation.Test case sheet
Requirement reference or text: [ ] Behavior under test (one per case): [ ] Setup and starting data: [ ] Action or input: [ ] Expected result: [ ] Where the expected result comes from: [ ] Evidence to capture: [ ] Boundary: lowest allowed value [ ] / just below [ ] Boundary: highest allowed value [ ] / just above [ ] Empty or missing input: [ ] Invalid input and expected message: [ ] Repeated or interrupted action: [ ] Question for the requirement owner: [ ] Answer and date: [ ]
Boundaries and circular tests
Check each expected result against the requirement or an explicit decision. Copying current behavior may preserve a bug, while computing an expected result with the same logic under test can miss the error you meant to catch. Include meaningful boundary values, invalid inputs and relevant interrupted states. Do not invent how an unspecified case should behave; list it as a question for the owner. Confirm that setup steps can put the system in the required state and that the result can actually be observed.
Ask another agent to check the result
Review these test cases against the requirement. Find boundary values and failure paths that are missing. Identify any test whose expected result only restates how the feature would be implemented, and say what independent source the expected result should come from instead.
Settle the open questions
Send the flagged ambiguities to whoever owns the requirement and record their answers beside the affected test cases. Mark which cases can be checked by hand and which need automation. Run the manual ones against a build or prototype when one exists, and note the evidence for each. Keep the list with the requirement so approval covers both.