Test Case Design Basics
Test Case Design
Basics
A hands-on walkthrough of deriving test conditions and test cases from a real specification — with a live interactive demo.
The Specification
Every test case starts with a specification. Consider the following requirement for an input screen in a system under test:
The input screen shall have three fields:
- A title field with a drop-down selector
- A surname field that can accept up to 20 alphabetic characters and the hyphen (-) character
- A first name field which can accept up to 20 alphabetic characters
All alphabetic characters shall be case insensitive. All fields must be completed. The data is validated when the Enter key is pressed.
If the data is valid the system moves on to the job input screen; if not, an error message is displayed.
Notice how much test-relevant information is packed into a single specification paragraph — field types, length limits, character sets, mandatory fields, trigger actions, and expected outcomes.
Breaking It Down
Before we can write test cases, we need to extract every testable attribute from the specification. Let's decompose each field:
Title Field
- Drop-down selector
- Mandatory (must be selected)
- Spec doesn't define valid options
Surname Field
- Max 20 characters
- Alphabetic + hyphen only
- Case insensitive
- Mandatory
First Name Field
- Max 20 characters
- Alphabetic only (no hyphen)
- Case insensitive
- Mandatory
System Behaviour Summary
Press Enter → Navigate to job input screen
Press Enter → Display error message
Defining Test Conditions
A test condition is a testable aspect of the system. From the specification, we can derive the following test conditions for the surname field alone:
Surname accepts alphabetic characters
Both upper and lowercase letters should be accepted (case insensitive)
Surname accepts the hyphen character
E.g., "Smith-Jones" should be valid
Surname rejects non-alphabetic characters (except hyphen)
Digits, special characters like @, #, !, etc. should trigger an error
Surname maximum length is 20 characters
Exactly 20 characters should be accepted; 21 should be rejected
Surname is a mandatory field
Leaving it empty should trigger an error
Specification Ambiguity
The spec says the surname can accept "up to 20 alphabetic characters and the hyphen." But it doesn't clarify: does the 20-character limit include the hyphen, or is it 20 alphabetic characters plus hyphens? This is exactly the kind of ambiguity testers are trained to find — and it must be resolved before test cases are finalised.
Deriving Test Cases
A test case transforms a test condition into a concrete, executable scenario. Each test case specifies:
Anatomy of a Test Case
To test the surname field, we would have to: navigate to the input screen, select a title, tab to the surname field (setting the precondition), enter a value (the first part of the input values), tab to the first name field and enter a value (the second part of the input values — needed because all fields must be completed), then press Enter. The system should either move to the job input screen (valid data) or display an error message (invalid data).
Navigate to input screen
Precondition — Get the system into the correct state
Select a title from drop-down
Precondition — Fulfil mandatory field requirement for title
Enter surname value (under test)
Primary input — The value being tested
Enter first name value
Supporting input — Must be valid so only the surname is under test
Press Enter → Observe result
Trigger action — Valid → job screen; Invalid → error message
Sample Test Cases for Surname Field
8 test cases| ID | Surname Input | Category | Expected |
|---|---|---|---|
| TC-01 | Smith |
Valid alphabetic | Accept ✓ |
| TC-02 | O'Connor |
Invalid: apostrophe | Reject ✗ |
| TC-03 | Smith-Jones |
Valid: hyphenated | Accept ✓ |
| TC-04 | Smith123 |
Invalid: digits | Reject ✗ |
| TC-05 | ABCDEFGHIJKLMNOPQRST (20 chars) |
Valid: boundary max | Accept ✓ |
| TC-06 | ABCDEFGHIJKLMNOPQRSTU (21 chars) |
Invalid: exceeds max | Reject ✗ |
| TC-07 | (empty) |
Invalid: mandatory | Reject ✗ |
| TC-08 | smItH |
Valid: case mix | Accept ✓ |
Interactive Demo
Try it yourself! Enter data into the form below and press Enter (or click Submit) to see how the validation works. Try both valid and invalid values to observe the system's behaviour.
Personal Details
All fields are required. Press Enter to validate.
Automated Test Execution
Click the button below to run the 8 test cases against the demo form automatically. Each test case will execute in sequence, showing the input, the expected result, and the actual result.
| ID | Surname | First Name | Expected | Actual | Status |
|---|---|---|---|---|---|
| TC-01 | Smith |
John |
Accept ✓ | — | — |
| TC-02 | O'Connor |
Anne |
Reject ✗ | — | — |
| TC-03 | Smith-Jones |
Alice |
Accept ✓ | — | — |
| TC-04 | Smith123 |
John |
Reject ✗ | — | — |
| TC-05 | ABCDEFGHIJKLMNOPQRST |
John |
Accept ✓ | — | — |
| TC-07 | (empty) |
John |
Reject ✗ | — | — |
| TC-08 | smItH |
JoHn |
Accept ✓ | — | — |
| TC-06 | ABCDEFGHIJKLMNOPQRSTU |
John |
Reject ✗ | — | — |
Key Takeaways
Specs Hide Test Conditions
A single specification paragraph can yield dozens of test conditions. Train yourself to read for testable attributes: data types, lengths, boundaries, mandatory fields, and triggers.
Spot the Ambiguities
Does "20 alphabetic characters and the hyphen" mean 20 total or 20 letters plus hyphens? Uncovering ambiguities is as valuable as writing test cases — perhaps more so.
Preconditions Matter
Testing one field doesn't mean ignoring the others. You must set up the right preconditions (select a title, provide valid supporting data) so that only the field under test can cause a failure.
Test Both Outcomes
Every validation has two paths: accept and reject. You must test both. A test that only verifies valid input misses half the story — the system must also correctly reject invalid input.
Validation Logic (Pseudocode)
Ready to Practice More?
Try deriving test cases for the first name field using the same methodology. Remember: no hyphens allowed!
Try the Exercise
Comments
Post a Comment