How to generate test cases from requirements
Turn an approved, testable requirement into traceable happy-path, invalid-partition and boundary cases with explicit setup and expected results.
Start with an approved requirement whose outcome can be observed. Give it a stable identifier, record the setup, select inputs from valid and invalid partitions plus the actual boundaries, and write an expected result that comes from the requirement rather than a guess. Link every case back to its source, review uncovered risks, and record pass or fail only after the case is run in a named environment.
Make the source requirement testable
Use an approved requirement with a stable identifier and an outcome a reviewer can observe. Separate combined behaviors when one sentence contains several independent conditions. If a limit, error message or permission rule is missing, return that ambiguity for review instead of turning a personal assumption into an expected result.
- Identify the subject and triggering condition.
- Name the observable response or state change.
- Record units, limits and permitted exceptions.
- Keep the requirement version with the test trace.
Write setup, action, data and expected result
A repeatable case identifies the preconditions and test configuration, provides the exact input or action, and states the expected observable result. Keep credentials and customer records out of fixtures. Give the case a stable identifier so failures, requirement changes and automation can refer to the same artifact.
Choose valid, invalid and boundary values deliberately
A successful example checks a valid partition; a negative example checks a declared invalid partition. Boundary value analysis applies to ordered partitions and targets the limit and its adjacent values. Do not call an unusual string a boundary unless an ordering and limit are defined. For combinations of conditions, use a decision table or another explicit model rather than sampling convenient examples.
Extend coverage from product risk
The labels happy, negative and boundary are a starting structure, not a sufficiency claim. Review state transitions, authorization by role, retries, duplicate actions, interruption, data volume, locale, accessibility and observable failure signals where the requirement or risk analysis makes them relevant. Give higher-risk behavior stronger and more independent evidence.
Keep planned cases separate from execution evidence
A matrix says what should be checked; it does not show that any check ran or passed. When executing, record the build, environment, test data version, actual result, status, time and linked defect. Maintain the trace when a requirement changes so stale tests and untested requirements remain visible.
Check the primary references
Check the source against the result
Requirement: Rows without an email address are rejected with a field-level message. Shared setup: the reviewer can open the CSV import screen. Supplied cases use a valid email, no email value and a whitespace-only email, with an explicit expected result for each.
The local generator creates TC-001 Happy path, TC-002 Negative path and TC-003 Boundary. The matrix reports three cases — one of each kind — repeats the shared precondition and traces every case to the exact rejection requirement.
The labels and trace do not prove that whitespace is a true product boundary, that the requirement is complete, that other email formats are covered or that any case passed. Review the specification, add risk-based cases and attach execution evidence in the real test system.
Structure one verified requirement into a matrix
Supply the requirement, shared preconditions and at least one explicit happy, negative and boundary scenario; generate numbered Markdown without inventing behavior.
Open Test Case Generator