DEV Community: Joy Odinaka

Test Design: How Do I Know What to Test?

Joy Odinaka — Wed, 02 Sep 2026 10:32:24 +0000

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

Email	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.

Starting with Manual QA

Joy Odinaka — Tue, 01 Sep 2026 10:17:11 +0000

After learning the difference between QA and testing, it’s time to get into the actual fundamentals.

I'm starting with Manual QA because I want to understand the thinking behind testing before moving into automation.

Here’s what I’m learning.

1. QA & Software Testing

QA (Quality Assurance) focuses on preventing quality problems by improving the process used to build software.

Software testing focuses on checking the software to find defects and verify that it behaves as expected.

A simple way to remember it:

QA -> How do we prevent problems?
Testing -> Can we find problems?

2. SDLC & STLC

Before testing software, I need to understand how software is built.

SDLC — Software Development Life Cycle

The overall process of developing software:

Requirements
     ↓
Design
     ↓
Development
     ↓
Testing
     ↓
Deployment
     ↓
Maintenance

STLC — Software Testing Life Cycle

The process specifically followed for testing:

Requirement Analysis
        ↓
Test Planning
        ↓
Test Case Design
        ↓
Test Environment Setup
        ↓
Test Execution
        ↓
Test Closure

SDLC is the bigger picture. STLC focuses on testing.

3. Test Scenarios vs Test Cases

A test scenario describes what needs to be tested.

A test case describes how to test it.

For a login feature:

Scenario:

Verify that a user can log in.

Test cases:

Think:

Scenario = What to test
Test case = How to test it

4. Bug / Defect Lifecycle

Finding a bug is only the beginning.

A typical defect lifecycle looks like:

New
 ↓
Assigned
 ↓
In Progress
 ↓
Fixed
 ↓
Retest
 ↓
Verified → Closed

But note that bugs can also be:

Reopened
Rejected
Duplicate
Deferred
Won't Fix

The important thing is that a defect should be tracked from discovery to resolution.

5. Severity vs Priority

These two confused me at first.

Severity: How badly does the bug affect the system?

Priority: How urgently should it be fixed?

For example:

A typo on the homepage might have low severity but high priority if the homepage is part of an important marketing campaign.

Another example:

A crash in a rarely used feature could have high severity but lower priority depending on the business context.

So:

Severity = Impact
Priority = Urgency

6. Positive vs Negative Testing

Positive testing

Check that the software works with valid input.

Example:

Enter a valid email and password -> Login should succeed.

Negative testing

Check how the software behaves with invalid or unexpected input.

Example:

Enter an incorrect password -> Login should fail with an appropriate message.

Good testers don't only ask: "Does it work?"

They also ask: "What happens when I do something I shouldn't?"

7. Functional vs Non-Functional Testing

Functional testing

Checks what the system does.

Examples:

Login
Registration
Search
Checkout
Payment

Non-functional testing

Checks how well the system works.

Examples:

Performance
Security
Usability
Reliability
Compatibility

A simple distinction:

Functional = What does it do?
Non-functional = How well does it do it?

8. Smoke, Sanity, Regression & Exploratory Testing

These testing types are easy to mix up.

Smoke Testing

A quick check to see if the build is stable enough for further testing.

"Does the application basically work?"

Sanity Testing

A focused check after a change or fix.

"Does this specific change work correctly?"

Regression Testing

Checks that new changes haven't broken existing functionality.

"Did this change break something that already worked?"

Exploratory Testing

Testing without following only predefined test cases.

The tester explores the application, asks questions, follows clues, and looks for unexpected behavior.

"What can I discover?"

9. Agile, Scrum & QA

Modern QA doesn't happen only after developers finish everything.

In an Agile team, QA is involved throughout development.

A typical Scrum team may include:

Product Owner
Scrum Master
Developers
QA/Testers

QA can contribute during:

Planning -> Development -> Testing -> Review -> Release

This means QA isn't simply the person who receives a finished product and looks for bugs.

QA works with the team to help build quality into the product.

What I'm Taking Away

Manual QA is much more than clicking buttons.

It's about:

Understanding -> Thinking -> Designing -> Testing -> Finding -> Communicating -> Verifying

And the biggest skill I'm beginning to develop is thinking about what could go wrong.

That's what I want to get better at.

What's Next?

Now that I have the fundamentals mapped out, it's time to learn Test Design.

I will be learning techniques such as:

Equivalence Partitioning
Boundary Value Analysis
Decision Table Testing
State Transition Testing
Error Guessing
Positive & Negative Testing

The journey continues.

What’s the Difference Between QA vs Testing?

Joy Odinaka — Sun, 30 Aug 2026 19:55:15 +0000

QA. Testing. Quality Control.

I used to think they were basically the same thing.

They are not.

So, what is QA?

Quality Assurance (QA) is about improving the process used to build software so that quality is built in from the start.

QA asks:

“How can we prevent problems?”

It looks at the bigger picture — processes, requirements, development, testing, and how the team works.

Then, what is Testing?

Software testing is about checking the actual software to find problems and verify that it behaves as expected.

Testing asks:

“Does this actually work?”

For example:

A developer builds a login page.

A tester might check:

Can a user log in with valid credentials?
What happens with the wrong password?
What if the email is empty?
What if the password is empty?
What happens after several failed attempts?

These checks can reveal defects before users do.

QA vs Testing

QA	Testing
Prevents quality problems	Finds problems
Process-focused	Product-focused
Starts early	Happens throughout development
Asks “How can we prevent defects?”	Asks “Can we find defects?”

They are different, but they work together.

What does a QA tester actually do?

A QA tester doesn't simply click around looking for bugs.

They:

Understand requirements
Think about what could go wrong
Design test cases
Execute tests
Report defects
Retest fixes
Perform regression testing
Explore the software
Communicate with developers and other team members

And perhaps most importantly:

They think like the user, and sometimes like the person trying to break the software.

What I'm learning

My biggest takeaway so far:

QA isn't just about finding bugs. It's about helping teams build better software.

That's a much bigger responsibility than I initially thought.

Next:
I will learn how software actually gets built following SDLC, and where QA fits into the process.

Getting Started in QA — Why Now?

Joy Odinaka — Sun, 23 Aug 2026 10:13:48 +0000

I’m starting my journey into Quality Assurance (QA).

And honestly, I’m starting from the beginning.

I want to understand how software is tested, how bugs are found, how quality is maintained, and what it really means to work as a QA tester.

Why QA?

Software is everywhere.

But good software isn't just about building features. It’s also about making sure those features work as expected.

Hence, QA.

I’m interested in learning how testers think:

What can go wrong?
How can I find it?
How do I know the software is working correctly?
How do I communicate a problem clearly?
How can testing help build better software?

Why now?

Because I don't want to keep waiting until I feel ready.

I have decided to learn by doing and document the journey as I go.

I won't pretend to be an expert.

I will learn something → practice it → make mistakes → fix them → write about it.

Hopefully, someone starting their own QA journey can learn alongside me.

The Road Ahead

I will start with Manual QA and gradually move toward automation.

My roadmap looks something like this:

Manual QA
Testing Fundamentals
Test Cases & Bug Reporting
API Testing
Test Automation
Real Projects QA Job Ready

I will document the things I learn, the things I struggle with, and the things that finally make sense.

Day 1 Starts Here

This is not a story about becoming an expert.

It's the beginning of a journey.

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

Next up:

What exactly is QA, and what does a QA tester actually do?