Gains:
- Ability to transform a requirement and acceptance criteria into comprehensive test cases with techniques such as equivalence classes, boundary value analysis and decision tables, with the support of artificial intelligence
- Ability to produce positive, negative and edge case scenarios separately and complete the edge cases missed by artificial intelligence with product information
- Ability to establish traceability and eliminate coverage gaps and unnecessary bloat by linking test cases to acceptance criteria
The tester's job often starts with this blank slate: he has a requirement ("the user must be able to reset his password") and he needs to turn this single sentence into dozens of concrete checks that will prove that the software actually works correctly. This transformation is called test design. Knowing the difference between a test scenario — a high-level objective that describes what to test, such as "invalid password should be rejected" — and a test case — an executable unit that details that scenario with concrete steps, input, and expected outcome is key. Artificial intelligence (AI) accelerates exactly this blank page moment: turning one requirement into dozens of draft scenarios in seconds. But remember — AI replicates what situations you can think of; You choose with your product knowledge which situations are really important.
In this unit, you will learn step by step how to turn a requirement into a comprehensive but clutter-free test suite with AI support.
Step by step: from requirement to test set
Step 1 — Clarify the requirement. Collect acceptance criteria (conditions that a job must meet to be considered “done”) before giving the AI the raw requirement. "Password must be resettable" is not enough; Rules such as "reset link is valid for 30 minutes", "the same password cannot be reused" are the source of the real test.
Step 2 — Implement testing techniques. Don't just say "write a script" about AI; Ask for classic test design techniques by name:
- Equivalence classes (equivalence partitioning): Dividing inputs into groups that are expected to produce the same behavior. For example, for the age field, "valid range", "too small", and "too large" are classes; Testing one example from each class is sufficient.
- Boundary value analysis: Testing threshold values based on the fact that errors occur most at the boundaries. It's like testing 17, 18, 19 separately for the 18 age limit.
- Decision table: Tabulating combinations of multiple conditions and the expected outcome of each combination.
- State transition: Testing the system's transitions from state to state (for example, order: created → paid → shipped) and invalid transitions.
Step 3 — Separate positive, negative, and edge states. Ask for a positive test (expected result with correct input), a negative test (proper error with invalid input), and an edge case — borderline or unusual cases. AI generally emphasizes the positive; Negative and edge cases are incomplete unless you explicitly request them.
Step 4 — Prioritize and prune. AI can generate 60 scenarios; They are not all of equal value. Prioritize those with high risk (money, security, data loss) and combine those that are duplicates.
Tip: Send a separate request to the AI saying "generate 5 unthinkable edge cases from this requirement". The most valuable contribution of AI is that it often reminds you of extraordinary situations that you have overlooked.
Weak prompt / Strong prompt
Weak: "Write test cases for password reset."
Strong: "Generate test cases for the 'password reset' feature with the following acceptance criteria: link valid for 30 minutes, single use, last 3 passwords cannot be reused, account locked for 15 minutes after 5 incorrect attempts. Apply equivalence classes and boundary value analysis. Give positive, negative and edge cases in separate headings. For each case: ID, prerequisite, steps, test data, expected result, associated acceptance criteria. Highlight security/locking scenarios take it."
Powerful prompt; It gives rules, techniques, output format and priority order. Thus, AI produces executable and traceable test cases, not decorative ones.
Test case output format
Ask for a structured format that can be imported directly into your team's test management tool (e.g. TestRail, Zephyr, Xray). The following table shows the components of a good test case:
area
Description
example
ID
unique ID
TC-PWD-014
Title
brief purpose
Expired link will be rejected
prerequisite
Condition required before testing
Reset link was generated 31 minutes ago
steps
Sequential actions
1. Click on the link 2. Enter new password
test data
Concrete values used
old link, new password "Abc!2345"
expected result
Behavior to be verified
"Link expired" error, password does not change
Acceptance criteria
traceability link
AK-3: link valid for 30 minutes
priority
Risk level
high
Four copyable templates
1) Technical based scenario production:
Your role: senior test designer.Generate test cases for feature: [feature and acceptance criteria].Apply: equivalence classes, breakpoint analysis, decision table.Provide output in 3 groups: Positive / Negative / Edge case.Each case: ID, precondition, steps, test data, expected result, associated acceptance criteria, priority (High/Medium/Low).
2) Edge case hunter:
List 10 normally overlooked edge cases for the following feature: [feature]. Write in one sentence why it's risky for each. Think about axes like empty/null, input too long, concurrency, timeout, format errors, Unicode/emoji, negative/zero, network outage.
3) Decision table production:
Create decision table for the following business rule: [rules].Columns: condition combinations; rows: each condition and expected action. Flag unachievable or conflicting combinations. Then propose a test case for each combination.
4) Traceability control:
Given the following list of acceptance criteria and the following test cases:[criteria] / [cases]. Show in tabular form which acceptance criteria are met by NO test cases (coverage gap) and which cases are not met by any criteria (redundant case).
three mini cases
Case 1 — Value of edge states. An expert from a fintech team had written 18 scripts for the money transfer feature. He applied the “edge case hunter” template to AI; AI reminded the situation of "transferring the same balance from two devices at the same time" (concurrency). When this scenario was tested, a double spend vulnerability was found and closed before going live. A single fringe situation prevented a potential six-figure loss.
Case 2 — Trimming the bulge. A team had the AI produce a script for the membership form and 74 cases came through. Running the traceability template found that 74 cases met only 9 acceptance criteria, with many retesting the same equivalence class. The set was reduced from 74 to 23 significant cases; run time decreased by 68%, coverage did not decrease.
Case 3 — Wrong assumption. The AI suggested testing invalid dates like “February 31st” for a date field, but did not know that the calendar component the team was using already blocked this. The expert eliminated 4 of the 6 date scenarios produced by the AI as unnecessary in the context of the product. AI generated possibilities; made a product information selection.
Common mistakes
- Requesting a script without giving acceptance criteria. Without knowing what is true, AI produces superficial scenarios that often miss the real risk.
- Just settling for positive tests. Explicitly not wanting negative and edge cases. This is where errors often lie.
- Accepting what is produced as it is. Forgetting that the AI does not know the product context and leaving unnecessary or impossible scenarios on the set.
- Bypassing traceability. Not linking cases to acceptance criteria; as a result, it is not seen which criterion is not tested (coverage gap).
- Quantity fallacy. Being happy because "60 scripts have been released". The value is not in the number, but in the scope that covers the risk.
In summary
Test design is about translating a one-sentence requirement into concrete, executable cases that prove the correctness of the software. AI greatly accelerates this transformation: it produces comprehensive blueprints when you give it acceptance criteria, classical testing techniques (equivalence classes, breakpoint, decision table, state transition) and a clear output format. But AI is biased toward the positive, doesn't know the product context, and can produce unnecessary bloat. Your job is to explicitly request negative and edge cases, establish traceability, prioritize by risk, and prune.
Application task
Choose a feature from your own project and write down the acceptance criteria. Have the AI generate test cases with the “technique-based scenario generation” template. Then apply the “edge case hunter” and “traceability check” templates. As a result: (1) add at least 3 edge cases that the AI skips, (2) prune cases that do not connect to any acceptance criteria, (3) write new cases if there are any acceptance criteria left untested. Pour the final set into a spreadsheet.
checklist
- [ ] Before requesting a script, I clarified the acceptance criteria.
- [ ] I asked YZ for equivalence classes and boundary value analysis by name.
- [ ] I generated positive, negative and edge states separately.
- [ ] I linked each test case to an acceptance criterion (traceability).
- [ ] I checked the scope gap and unnecessary cases with the table.
- [ ] I prioritized by risk and pruned the swollen set.