So far, I have learned the fundamentals of Manual QA.
Now comes a question that sounds simple:
If I have a feature to test, what exactly should I test?
That's where Test Design comes in.
Test design is about deciding what test cases to create so that we can test a feature effectively without having to test every possible combination.
Here are the techniques I learnt.
1. Equivalence Partitioning
Instead of testing every possible input, we divide inputs into groups that should behave similarly.
These groups are called equivalence partitions.
Example
A website allows users to enter an age between 18 and 60.
We can divide the inputs into:
Below 18 → Invalid
18 - 60 → Valid
Above 60 → Invalid
Instead of testing every age, we can test representative values:
- 17 → Invalid
- 30 → Valid
- 61 → Invalid
The idea is:
Test one or more values from each group instead of testing everything.
2. Boundary Value Analysis
Bugs often hide around the edges of valid ranges.
Boundary Value Analysis (BVA) focuses on those edges.
Using the same age requirement:
18 to 60
We test:
17 → Just below
18 → Minimum
19 → Just above
59 → Just below maximum
60 → Maximum
61 → Just above
Why?
Because developers can accidentally implement:
age > 18
instead of:
age >= 18
The boundary is where things often go wrong.
If there's a boundary, test around it.
3. Decision Table Testing
Some features behave differently depending on multiple conditions.
Decision tables help us organize these combinations.
Example: Login
Suppose login succeeds only when:
- Email is valid
- Password is correct
| Password | Expected Result | |
|---|---|---|
| Valid | Correct | Login succeeds |
| Valid | Incorrect | Login fails |
| Invalid | Correct | Login fails |
| Invalid | Incorrect | Login fails |
Instead of trying to remember every combination, the decision table makes the rules visible.
When multiple conditions affect the outcome, think in combinations.
4. State Transition Testing
Some systems behave differently depending on their current state.
A simple example is a user account.
Imagine an account is locked after 3 failed login attempts.
Active
↓
1 failed attempt
↓
Active
↓
2 failed attempts
↓
Active
↓
3 failed attempts
↓
Locked
Now we can test:
- Successful login → Account remains active
- 1 failed attempt → Account remains active
- 2 failed attempts → Account remains active
- 3 failed attempts → Account becomes locked
- Login after lock → Access denied
The key question is:
"What happens when the system moves from one state to another?"
5. Error Guessing
This one is different.
There isn't a strict formula.
It's about using experience, intuition, and knowledge of common mistakes to predict where bugs might exist.
For a registration form, I might try:
- Empty fields
- Very long inputs
- Special characters
- Spaces
- Duplicate email
- Invalid email format
- Copy/paste unexpected values
- Rapidly clicking the submit button
I'm basically asking:
"If I wanted to break this feature, what would I try?"
The more experience a tester gains, the better they become at guessing where problems might hide.
6. Positive & Negative Testing
These are two fundamental ways of approaching a test.
Positive Testing
Use valid input and verify that the system works as expected.
Example:
Valid email + Valid password = Login succeeds
Negative Testing
Use invalid, unexpected, or inappropriate input and verify that the system handles it correctly.
Example:
Invalid email + Valid password = Login rejected
A good tester asks both:
"Does it work when I use it correctly?"
and
"What happens when I don't?"
Putting It Together
Let's say I'm testing a product quantity field that accepts values from 1 to 10.
I could use several techniques:
Equivalence Partitioning
< 1 → Invalid
1 - 10 → Valid
> 10 → Invalid
Boundary Value Analysis
0, 1, 2
9, 10, 11
Positive Testing
Enter 5 → Should be accepted
Negative Testing
Enter 0 → Should be rejected
Enter 11 → Should be rejected
Enter "abc" → Should be rejected
Error Guessing
I might also try:
Empty value
Negative number
Decimal number
Very large number
Special characters
Spaces
Now I'm not just randomly clicking around.
I'm designing tests with a reason.
What I Have Learned
Test design has changed how I think about testing.
Before:
"Let me test this feature."
Now:
"What are the possible inputs, conditions, states, boundaries, and failure points?"
That's the mindset I'm trying to develop.
Testing isn't about testing everything but more about choosing the right things to test.
What's Next?
The next step is to turn these techniques into something practical:
Writing professional test cases.
Top comments (0)