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?

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.

1. Equivalence Partitioning

Instead of testing every possible input, 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 to 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, we 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

Instead of trying to remember every combination, the decision table makes the rules visible.

When multiple conditions affect the outcome, it is best to think in combinations.

4. State Transition Testing

Some systems behave differently depending on their current state.

An example is a user account.

Let's say 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

We ask:

"What happens when the system moves from one state to another?"

5. Error Guessing

This one is different because there isn't a strict formula.

It is about using experience, intuition, and knowledge of common mistakes to predict where bugs might exist.

For a registration form, we 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 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

As a good tester you always ask:

"Does it work when I use it correctly?"

and

"What happens when I don't?"

Testing a product quantity field that accepts values from 1 to 10.

We 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 am not just randomly clicking around, but I am designing tests with a reason.

What I Have Learned

Test design has changed how I think about testing. I don't just jump into testing a feature, But I first check the possible inputs, conditions, states, boundaries, and failure points?

Testing isn't about testing everything but more about choosing the right things to test.

I'm learning QA and I'm taking you with me.