Software Quality Assurance Introduction

What is Software Quality Assurance?#

Software Quality Assurance (SQA) is everything a team does to make sure the software it ships does what users need, reliably — not just finding bugs at the end, but preventing them throughout the project. It covers how requirements are reviewed, how code is reviewed and tested, how releases are approved, and how quality is measured over time.

A useful way to think about it: testing tells you the current state of quality; QA changes the process so the next release starts from a better place.

QA vs QC vs testing#

These three terms get used interchangeably, but interviewers (and good teams) distinguish them:

Testing is one activity inside QC, and QC is one part of QA.

Verification vs validation#

• Verification — "Are we building the product right?" Checking work products against their specification: reviewing a design, walking through requirements, static analysis.
• Validation — "Are we building the right product?" Checking that the running software meets real user needs: system testing, user acceptance testing, beta feedback.

A login page can pass verification (it matches the spec exactly) and still fail validation (users can't find the "forgot password" link).

The seven testing principles#

These come from the ISTQB syllabus and show up in almost every QA interview:

1. Testing shows the presence of defects, not their absence. A passing suite means you didn't find bugs, not that none exist.
2. Exhaustive testing is impossible. A form with three 10-character fields has more input combinations than you could ever run — so you choose tests by risk.
3. Early testing saves time and money. A requirement ambiguity fixed in review costs minutes; the same defect found in production can cost days.
4. Defects cluster together. A small number of modules usually contain most of the bugs — spend more effort there.
5. Beware the pesticide paradox. Running the same tests forever stops finding new bugs. Review and refresh them.
6. Testing is context-dependent. A banking app and a mobile game need very different testing.
7. Absence-of-errors is a fallacy. Bug-free software that doesn't meet user needs is still a failure.

What a QA engineer actually does#

A typical week for a QA engineer on an agile team:

• Reviews user stories before development starts and asks "what should happen when…?" questions that expose missing acceptance criteria.
• Writes test scenarios and test cases for upcoming features.
• Tests features as soon as they're ready — manually and with automated checks.
• Raises clear bug reports and verifies the fixes.
• Maintains the regression suite and the automation framework.
• Reports on quality: what was tested, what's risky, and whether a release is ready.

Why quality is everyone's job#

Modern teams treat quality as a whole-team responsibility. Developers write unit tests and review each other's code; product owners write clear acceptance criteria; QA engineers bring a tester's mindset, design the test strategy, and build the automation that lets everyone move fast safely. The QA engineer's value isn't being the last gate — it's helping the team find problems as early and cheaply as possible.

What you'll learn in this track#

1. SDLC, STLC & the QA Process — where testing fits in a project.
2. Test Levels & Test Types — unit to acceptance, functional to performance.
3. Test Planning & Strategy — deciding what to test and how much.
4. Quality Metrics & Reporting — measuring quality honestly.

Then continue with Manual Testing and Test Automation.