QA ENGINEERING GUIDE

Software Testing Basics

The types, levels and phases of software testing explained for beginners and QA engineers.

Why testing matters

Testing answers a simple question: does this software behave the way it should? It validates requirements, protects users from defective features and prevents expensive bugs from reaching production.

Good testing is not just about finding failures. It also builds confidence that a release is safe to ship, documents expected behavior and gives developers fast feedback on every change.

Levels of testing

Testing happens at different levels of the system. Unit tests verify a single function or class in isolation, while integration tests check that two or more components work together correctly.

• Unit — fast, isolated checks of individual functions or modules.
• Integration — verifies interactions between modules, services or databases.
• System — tests the complete application as one whole, end to end.
• Acceptance — confirms the product meets business requirements and is ready to release.

Types of testing

Types describe the questions a test is asking. Functional testing checks what the system does, while non-functional testing checks how it performs, such as speed, security and usability.

• Functional vs non-functional — behavior versus qualities like performance and reliability.
• Manual vs automated — human-driven verification versus scripted checks run by a framework.
• Smoke — a quick pass over critical paths to see if the build is even runnable.
• Regression — confirms new changes did not break existing functionality.
• Sanity — a narrow, focused check after a specific fix or small change.
• Exploratory — simultaneous learning, design and execution without prewritten steps.

When testing happens in the SDLC

Testing is not a single phase at the end. In a waterfall model it appears before release, but in agile it runs continuously within every sprint alongside development.

In agile teams testing shifts left: testers design cases while stories are still in refinement, automation runs on every commit and regression suites protect each increment. The goal is to find defects as early as possible, when they are cheapest to fix.

What a good test strategy contains

A test strategy aligns testing with project risk. It defines the scope, the test levels used, the environments, resources, tools and the entry and exit criteria for each release.

It should also state what is explicitly out of scope, how defects are prioritized and which metrics are tracked. A strategy that nobody reads is worthless, so keep it concise and update it as the project evolves.

Common testing metrics

Metrics help teams answer whether testing is sufficient. Test coverage measures how much of the code or requirements exercises are covered, though high coverage alone does not guarantee quality.

• Pass rate — percentage of executed tests that passed.
• Defect density — number of defects found per module or per thousand lines of code.
• Defect leakage — serious bugs that escaped testing and reached production.
• Execution status — blocked, failed, passed and retest counts on any given day.