DEV Community: Joy Odinaka

Test Planning: Before I Start Testing

Joy Odinaka — Fri, 02 Oct 2026 01:06:07 +0000

So far, I have learned how to:

Understand requirements
Design tests
Write test cases
Execute tests
Report bugs
Document results

But before all of that, there is an important question:

What exactly are we going to test, and how are we going to test it?

Test Planning?

Test planning is the process of deciding what will be tested, how it will be tested, who will do it, and when it will happen.

A test plan gives the team a clear direction before testing begins.

What Goes Into a Test Plan?

A test plan can include:

1. Scope

What are we testing?

Defining scope helps prevent confusion about what the team is responsible for testing.

For a food delivery application, for example:

In scope:

Registration
Login
Restaurant search
Viewing menus
Adding food to cart
Placing orders
Order history

Out of scope:

Payment gateway
Delivery processing
Password reset

2. Testing Types

We also decide what types of testing are needed. The types selected depend on the application and its requirements.

For example:

Functional testing
Regression testing
Exploratory testing
Negative testing
Smoke testing
Usability testing
Compatibility testing

3. Test Environment

Where will testing happen?

The environment matters because software can behave differently across browsers, devices, and configurations.

For example:

Browser:
Chrome
Firefox

Devices:
Desktop
Android

Database:
Test Database

4. Roles and Responsibilities

Who is involved?

Everyone should understand their role during testing.

A test plan can define responsibilities for:

QA Tester
QA Lead
Developer
Product Owner
Scrum Master

5. Schedule

Testing doesn't happen randomly.

Schedule gives the team an idea of what happens when.

We can plan activities such as:

Requirement Review
       ↓
Test Planning
       ↓
Test Scenario Design
       ↓
Test Case Design
       ↓
Test Execution
       ↓
Bug Reporting & Retesting
       ↓
Test Closure

Entry and Exit Criteria

Another thing I learned is that testing needs clear conditions for starting and finishing.

Entry Criteria

Conditions that should be met before testing begins.

For example:

Requirements are available
Test environment is ready
Test data is available
Build is deployed

Exit Criteria

Conditions that help determine when testing can be considered complete.

For example:

Planned tests have been executed
Critical defects are resolved
Test results are documented
Required coverage has been achieved

Risks and Assumptions

Things don't always go according to plan.

A test plan can also identify potential risks.

For example:

The test environment may not be available on time.

Or:

A required test API may be unavailable.

Identifying risks early allows the team to think about how to handle them.

Test planning has changed the way I think about testing. I don't just start testing immediately I am giving the application.

Now I first define:

What we are testing
What's not included
How we will test it
Who is responsible
What is needed
When we can start and finish

Testing isn't something we simply start doing without a plan.

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

Test Execution & Documentation

Joy Odinaka — Tue, 29 Sep 2026 16:33:45 +0000

I have learned how to design tests, and the next is how to actually document and run them.

I need to execute the tests, record what happened, report problems, and keep track of what has been tested.

1. Test Case Execution

A test case tells me what to test and how to test it.

During execution, I follow the steps and compare the actual result with the expected result.

For example:

Test: Login with valid credentials

Expected: User should be successfully logged in.

Actual: User is successfully logged in.

Result: PASS ✅

But what if the login fails?

Actual: Error message: "Invalid credentials"

Result: FAIL ❌

And here, documentation becomes important.

2. Test Status

Not every test will simply be Pass or Fail.

Common statuses include:

Status	Meaning
Pass ✅	Expected result was achieved
Fail ❌	Actual result differs from expected result
Blocked 🚫	Test cannot be executed because of a blocker
Not Run ⏳	Test hasn't been executed yet

This gives the team a quick picture of the current testing progress.

3. Expected vs Actual Result

One thing I'm learning is to keep these two separate.

Expected Result -> What should happen?

Actual Result -> What actually happened?

This difference is very important when reporting a bug.

Instead of saying:

"Login doesn't work."

I should be able to say:

Expected: User should log in with valid credentials.
Actual: User remains on the login page and receives an error message.

That's much easier for someone else to understand and investigate.

4. Bug Reporting

When a test fails because of a defect, I need to report it clearly.

A useful bug report usually contains:

Bug ID
Title
Description
Steps to reproduce
Test data
Expected result
Actual result
Severity
Priority
Environment
Screenshots or other evidence

The goal isn't simply to say that there's a bug.

The goal is to give the developer enough information to reproduce and understand the problem.

5. Retesting vs Regression Testing

When a developer fixes a bug, I don't just assume it's fixed.

I retest it to know if the specific bug got fixed.

For example:

A login bug was reported.

The developer fixes it.

I run the same steps again to verify the fix.

Next, I do a Regression Testing to know if the fix broke anything else?

I test related or existing functionality to make sure the change hasn't introduced new problems.

So:

Retesting -> Check the fix

Regression -> Check for unintended impact

6. Test Execution Reports

As testing progresses, the team needs to know what's happening.

For example:

Total Tests:      50
Executed:         38
Passed:           32
Failed:            6
Blocked:           4
Not Run:           8

From this, we can calculate useful metrics such as:

Test coverage
Pass rate
Fail rate
Blocked tests
Remaining tests

The numbers help communicate the current state of testing.

7. Requirements Traceability Matrix

Another useful document is the RTM - Requirements Traceability Matrix.

It connects requirements to test cases and, where applicable, defects.

For example:

Requirement	Test Case	Result	Bug
User can log in	TC-LOGIN-001	Fail	BUG-001
User can search products	TC-SEARCH-001	Pass	—

This helps answer:

"Have we tested all the requirements?"

And if something fails:

"Which requirement and test case are affected?"

What I am Learning

Test execution has taught me that testing isn't finished when I click Run.

Good QA also means:

Execute → Observe → Compare → Document → Report → Retest → Verify

The quality of the documentation matters because testing is a team activity.

Someone else should be able to understand:

What I tested
What happened
What failed
Why it failed
What has been fixed
What still needs attention

I will start working on a small QA project, creating test scenarios, test cases, executing them, reporting bugs, and documenting the results.

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

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?

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

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

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.

1. QA vs 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.

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

This is the overall process of developing software:

Requirements
     ↓
Design
     ↓
Development
     ↓
Testing
     ↓
Deployment
     ↓
Maintenance

STLC — Software Testing Life Cycle

This is 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:

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

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

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.

My Take 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?

I will be learning test design techniques such as:

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

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

Quality Assurance vs Testing?

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

My first note:

Software Quality Assurance vs Software Testing

What is Quality Assurance (QA)?

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

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

What is Testing?

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

For example:

A developer builds a login page.

A tester checks:

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 does not 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.

QA is about helping teams build better software and not just only finding bugs.

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

Getting Started in QA

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

I am starting my journey into Quality Assurance (QA), and I am 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/engineer.

Software is everywhere but good software is about building features and making sure those features work as expected.

I am 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?

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.

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

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

This is no story about becoming an expert, but it is the beginning of a journey.

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