1
Module 01
Anatomy of a Good Test Case
What separates a professional test case from a useless one.
The Golden Rule
A good test case is atomic (one condition per case), reproducible (any tester can run it), clear (no ambiguity), and traceable (linked to a requirement). If another tester can't run your test case without asking questions — it's not done.
Test Case ID REQUIRED
TC-LOGIN-001 — Unique identifier for tracking and referencing.
Title REQUIRED
Verify login with valid credentials — Short, descriptive action.
Preconditions REQUIRED
User account exists. App is running. Browser is open.
Test Steps REQUIRED
Numbered, specific actions: 1. Open /login 2. Enter email 3. Enter password 4. Click Login
Test Data REQUIRED
Email: user@example.com / Password: Test1234! — exact values, no vagueness.
Expected Result REQUIRED
User is redirected to /dashboard. Welcome message displayed.
Actual Result ON EXECUTION
Filled during test execution — what actually happened.
Priority RECOMMENDED
High / Medium / Low — helps prioritize execution order.
Real Example — Login Feature
| ID | Title | Preconditions | Steps | Data | Expected Result | Type |
|---|---|---|---|---|---|---|
| TC-LOGIN-001 | Login with valid credentials | Account exists | 1.Open /login 2.Enter email 3.Enter pass 4.Click Login | user@example.com / Test1234! | → /dashboard ✅ | Positive |
| TC-LOGIN-002 | Login with wrong password | Account exists | 1.Open /login 2.Enter email 3.Enter wrong pass 4.Click Login | user@example.com / WrongPass! | Error: "Invalid credentials" ❌ | Negative |
| TC-LOGIN-003 | Login with empty fields | App is running | 1.Open /login 2.Leave fields empty 3.Click Login | — (empty) | Required field errors shown ❌ | Edge |
| TC-LOGIN-004 | Login with SQL injection | App is running | 1.Open /login 2.Enter injection string 3.Click Login | ' OR 1=1 -- | Access denied — no bypass ❌ | Security |
💡 Key insight
Notice TC-LOGIN-004 — security testing belongs in test cases too. SQL injection is one of the most common vulnerabilities. If you're not testing it, someone else will — from the outside.
✏️ Exercise — Write Your Own Test Case
Complete the test case for the scenario below. Fill in every field.
Scenario: An e-commerce checkout form has a promo code field. Users can enter a discount code before completing their purchase. Write a negative test case for an invalid promo code.
🔍 Quick Check
Test your understanding of test case anatomy
2
Technique 01
Boundary Value Analysis
Test at the edges — that's where the bugs live.
Definition
BVA tests values at and just outside the boundaries of valid ranges. If a field accepts 1–100, you must test: 0 (just below min), 1 (min), 100 (max), 101 (just above max). Four values. Full boundary coverage.
Visual: Age field accepts 18–65
INVALID
< 18
< 18
VALID RANGE
18 — 65
18 — 65
INVALID
> 65
> 65
17
Just below ❌
18
Min valid ✅
41
Midpoint (skip)
65
Max valid ✅
66
Just above ❌
Real Example — E-Commerce: Quantity Field (1–99)
| ID | Input Value | Boundary Type | Expected Result | Status |
|---|---|---|---|---|
| TC-QTY-001 | 0 | Just below min | Error: "Minimum quantity is 1" | ❌ Fail |
| TC-QTY-002 | 1 | Minimum valid | Accepted — item added to cart | ✅ Pass |
| TC-QTY-003 | 99 | Maximum valid | Accepted — 99 items in cart | ✅ Pass |
| TC-QTY-004 | 100 | Just above max | Error: "Maximum quantity is 99" | ❌ Fail |
| TC-QTY-005 | -1 | Negative value | Error: "Invalid quantity" | ❌ Fail |
💡 Why boundaries break systems
Developers often write
if (qty > 0 && qty < 100) instead of qty <= 99. The difference: 99 passes the first check but 100 also passes. Off-by-one errors at boundaries are among the most common bugs in production.✏️ Exercise — Apply BVA
Generate the correct boundary test values for the scenario below.
Scenario: A contact form has a "Message" text field that accepts between 10 and 500 characters. Using Boundary Value Analysis, what are the 4 values you MUST test?
🔍 Quick Check
BVA in action
3
Technique 02
Equivalence Partitioning
Test smart — one value per partition covers the whole group.
Definition
EP divides input data into partitions where the system should behave the same way. Test one representative value from each partition — if it passes, the whole partition should pass. This dramatically reduces test cases without losing coverage.
Real Example — Registration: Age Field
| Partition | Range | Representative Value | Expected Behavior | Valid? |
|---|---|---|---|---|
| Too young | < 18 | 15 | Error: "Must be 18 or older" | Invalid ❌ |
| Valid adult | 18–64 | 30 | Registration proceeds | Valid ✅ |
| Senior | 65–99 | 70 | Registration proceeds | Valid ✅ |
| Too old | > 99 | 120 | Error: "Invalid age" | Invalid ❌ |
| Non-numeric | Text | "abc" | Error: "Numbers only" | Invalid ❌ |
| Empty | — | (blank) | Error: "Required field" | Invalid ❌ |
BVA + EP Together
These techniques complement each other. EP identifies the partitions. BVA tests the edges between them. Use both together for maximum coverage with minimum test cases.
✏️ Exercise — Define Partitions
Identify the equivalence partitions for this scenario.
Scenario: A promo code field on a checkout form accepts alphanumeric codes of exactly 8 characters (e.g., "SUMMER24"). How many partitions would you define? Select all that apply.
🔍 Quick Check
Equivalence Partitioning
4
Technique 03
Decision Table Testing
When multiple conditions combine to determine outcomes.
Definition
Decision tables are used when system behavior depends on combinations of multiple conditions. Each column in the table is a rule — a unique combination of conditions and its expected action. No combination goes untested.
Real Example — E-Commerce: Free Shipping Logic
Rule: Free shipping if order > $50 OR user has Premium membership. Express shipping only for Premium members.
| Condition / Rule | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|
| Order total > $50 | Y | Y | N | N |
| Premium member | Y | N | Y | N |
| → Free shipping | ✅ | ✅ | ✅ | ❌ |
| → Express available | ✅ | ❌ | ✅ | ❌ |
| → Standard only | ❌ | ❌ | ❌ | ✅ |
4 rules → 4 test cases. Every combination covered.
💡 When to use Decision Tables
Use decision tables when a feature has 2 or more conditions that combine to produce different outcomes. Login rules, discount logic, permission systems, form validation with multiple fields — all perfect candidates. If you can write it as "if A and B then X, if A and not-B then Y" — use a decision table.
🔍 Quick Check
Decision Table Testing
5
Technique 04
State Transition Testing
Test how a system moves between states — and what happens at the boundaries.
Definition
State Transition tests the valid and invalid transitions between system states. A system is always in a state. Events trigger transitions. Testing ensures valid transitions work correctly — and invalid ones are blocked.
Real Example — User Account States
PENDING
Just registered
→ verify email →
ACTIVE
Verified
→ 3 failed logins →
LOCKED
Temporarily blocked
→ admin unlock →
ACTIVE
| ID | Current State | Event / Action | Expected Next State | Expected Behavior |
|---|---|---|---|---|
| TC-ST-001 | PENDING | User clicks verify link | ACTIVE | ✅ Account activated |
| TC-ST-002 | PENDING | Link expires (48h) | EXPIRED | ❌ Show re-send option |
| TC-ST-003 | ACTIVE | 3 failed login attempts | LOCKED | ❌ Show lockout message |
| TC-ST-004 | LOCKED | User tries to login | LOCKED | ❌ Still blocked — no bypass |
| TC-ST-005 | LOCKED | Admin unlocks account | ACTIVE | ✅ User can login again |
| TC-ST-006 | PENDING | Try to login before verifying | PENDING | ❌ "Verify email first" |
💡 The invalid transition test
TC-ST-004 and TC-ST-006 test invalid transitions — trying to do something from the wrong state. These are the most commonly missed tests. Developers test the happy path. QA tests what happens when someone tries to skip steps or move to invalid states.
🔍 Quick Check
State Transition Testing
📄
Resources
Downloadable Templates
Professional templates ready to use in your next QA project.
Standard Test Case Template
ID, Title, Preconditions, Steps, Data, Expected Result, Status, Priority
BVA Test Case Template
Field, Min, Max, Just Below, Min Valid, Max Valid, Just Above
Decision Table Template
Conditions × Rules matrix with actions — ready to fill
State Transition Template
Current State, Event, Next State, Expected Behavior, Valid/Invalid