Joy Odinaka

Posted on Sep 1

Starting with Manual QA

#testing #qa #beginners

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.

DEV Community