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:

• Login with valid credentials
• Login with an incorrect password
• Login with an empty email
• Login with an empty password
• Login with both fields empty

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.