Test Levels | QA Decoded

Without defined test levels, critical gaps appear between what developers test and what users experience

A developer unit-tests a payment calculation function — it works perfectly in isolation. But when combined with the currency conversion service and the tax calculation module, it produces incorrect totals. No one tested the integration.

Test levels define who tests what, at what stage, and against which test basis. They prevent both overlap (testing the same thing multiple times) and gaps (missing entire categories of defects).

// example: github — testing at every level

Scenario: GitHub's pull request merge feature involves multiple components: the diff engine, the merge algorithm, branch protection rules, notification service, and CI/CD integration. What happened: GitHub developers write unit tests for individual functions (does the diff algorithm correctly identify added/removed lines?). Integration tests verify that the merge algorithm correctly triggers branch protection checks. System tests verify the end-to-end merge flow across all services. GitHub's enterprise customers run acceptance tests in their own environments to verify the feature meets their compliance requirements. Why it matters: A defect in branch protection logic would not be found by unit tests alone. Each level catches a different category of defect.

The Four Test Levels — CTFL 4.0.1

Component Testing (Unit Testing)

Tests individual components (functions, classes, modules) in isolation. Typically performed by developers. Test basis: component specifications, detailed design, code. Focus: logic, data handling, boundary conditions.

Integration Testing

Tests interactions between components or systems. Verifies interfaces and data flow. Test basis: software design, architecture, interface specifications. Two types: component integration testing (within a system) and system integration testing (between systems/APIs).

System Testing

Tests the complete, integrated system against system requirements. Typically performed by an independent test team. Test basis: system requirements, use cases, risk analyses. Covers both functional and non-functional aspects.

Acceptance Testing

Validates the system meets business needs and is ready for deployment. Performed by users, customers, or business representatives. Types include: User Acceptance Testing (UAT), Operational Acceptance Testing (OAT), and Contractual/Regulatory Acceptance Testing.

// tip: Exam Tip: Know the "test basis" for each level — the documents or artefacts used to design tests. Component testing uses detailed design/code. Integration testing uses architecture/interface specs. System testing uses system requirements. Acceptance testing uses business requirements and user stories.

Test Levels Applied: Ride-Hailing App Feature

Feature: Driver location updates in real time on the passenger app

Level	What is Tested	Who Tests	Defect Example Found
Component	GPS coordinate parsing function	Developer	Coordinates truncated after 4 decimal places
Integration	GPS service → Map rendering API → Passenger app	QA Engineer	Location updates arrive but map does not re-render
System	Full booking flow with live location tracking	Test Team	Location freezes when driver enters a tunnel
Acceptance	Does the feature meet the product requirement: "Driver location updates every 3 seconds"	Product Owner / Beta Users	Update frequency is 8 seconds on older Android devices

Acceptance Testing

Scope

Business readiness and fitness for purpose

Who tests

Users, customers, product owner

Test basis

Business requirements, user stories, contracts

Defects found

Missing business rules, usability gaps, compliance issues

// Example defect at this level

Feature works but does not meet the "3-second update" requirement

// Exam tip

Know the test basis for each level — questions often ask which documents are used to design tests at component vs acceptance level.

Test Levels Comparison

Aspect	Component	Integration	System	Acceptance
Scope	Single component	Component interactions	Entire system	Business fit
Test basis	Code, detailed design	Architecture, interfaces	System requirements	Business requirements, contracts
Typical tester	Developer	Developer or QA	Independent QA team	Users, business stakeholders
Environment	Dev environment / mocks	Test environment with real services	System test environment	Production-like or production
Defects found	Logic errors, unit-level bugs	Interface mismatches, data flow	End-to-end failures, performance	Missing business requirements

// warning: Exam Trap: "Test levels must always be executed sequentially." This is false in Agile and iterative models. In Scrum, all test levels can occur within a single sprint. CTFL acknowledges that test levels may overlap. The key is that each level has a distinct objective and test basis — not that they must be strictly sequential.

Exam Practice Questions

// ctfl 4.0.1 style — select an answer to reveal explanation

Q1.A tester is verifying that the payment API correctly sends confirmation data to the notification service. Which test level is this?

Q2.Which test level uses "business requirements and user stories" as its primary test basis?

Q3.Operational Acceptance Testing (OAT) is BEST described as: