2.3 Test Levels: Component Through Acceptance

What a Test Level Is

A test level is a specific instantiation of a test process organized around a clear set of objectives. CTFL v4.0 characterizes each level by five attributes you should be able to recall: its objectives, test basis (the source from which tests are derived), test object (what is tested), typical defects and failures found, specific approaches and responsibilities, and the test environment used. The syllabus defines five test levels.

Component testing (also called unit or module testing) focuses on individual components — functions, classes, modules, or services — that are separately testable. It is usually performed by developers in their development environment, and it relies on stubs, drivers, and mocks to isolate the component from the parts it depends on. A stub replaces a called-but-not-yet-available component, a driver replaces a calling component to invoke the item under test, and a mock simulates a depended-on component and can verify how it was called.

Typical defects: incorrect logic, wrong calculations, and faulty boundary handling local to the unit.

Component integration testing focuses on the interfaces and interactions between components that have already passed component testing. Its test basis includes software and system design, sequence diagrams, and interface specifications. Typical defects: inconsistent message structures, incorrect data passed across interfaces, interface mismatches, and timing or sequencing failures.

System and System Integration Testing

System testing evaluates the behavior and capabilities of the whole, integrated system, often the end-to-end tasks it performs and the non-functional behavior it exhibits. The test basis includes system and software requirement specifications, risk-analysis reports, use cases, epics and user stories, and models of system behavior. Test objects are applications, hardware/software systems, and the data they handle. System testing should use an environment that matches the production target as closely as possible. It is frequently performed by an independent test team.

System integration testing focuses on the interactions between the system and its external environment — other systems, microservices, external interfaces, third-party services, cloud services, and infrastructure. Because external parties may be involved and not fully controllable, this level can surface defects only visible when real external systems are connected.

Acceptance Testing and Its Four Forms

Acceptance testing, like system testing, typically targets the behavior of the whole system, but its objective is different: it establishes confidence in the system and validates that it is fit for purpose and ready for delivery, rather than only finding defects. CTFL v4.0 names four common forms:

• User acceptance testing (UAT) — validates fitness for use by intended users in a real or simulated operational environment, focused on business processes.
• Operational acceptance testing (OAT) — performed by operations/system-administration staff; checks backup/restore, installation, disaster recovery, security, performance under load, and maintenance tasks.
• Contractual and regulatory acceptance testing — verifies conformance to contract acceptance criteria or to laws, standards, and safety regulations.
• Alpha and beta testing — performed by potential or existing users; alpha at the developer's site, beta at the users' own sites, to gain feedback from the market before full release.

Level Versus Type, and Common Traps

The same test type can be applied at any level: performance (a non-functional type) can be tested at component, integration, system, or acceptance level. Do not equate a level with a type. A frequent exam trap is labeling any user-facing test as acceptance testing — if the test team evaluates the complete system against system requirements, that is system testing; only when stakeholders judge fitness for purpose is it acceptance testing. Another trap: assuming component testing must be done by developers only — it usually is, but the defining attribute is the test object (an isolated component), not the job title.

When answering level questions, identify the test object and objective first.

Test Basis and Typical Defects by Level

The exam often gives a scenario and asks for the level, or gives a level and asks for its typical defects or test basis. Memorize the mapping below; it consolidates the five attributes the syllabus assigns to each level.

Notice that test bases move from low-level design at the component level toward business and contractual sources at the acceptance level — this trend mirrors the V-model pairing in 2.1.

Why Multiple Levels Reduce Cost and Risk

Levels exist because each catches a different class of defect close to where it is cheapest to fix. A division-by-zero bug is far cheaper to catch in component testing (a developer fixes it in seconds) than in system testing (where it manifests as a confusing end-to-end failure that someone must first localize). Conversely, an emergent problem — say, two correctly built subsystems that disagree on a date format — can only appear once they are integrated, so component testing alone can never find it.

This is why CTFL warns against relying on a single level: skipping component testing pushes localizable defects into expensive late levels, while skipping integration or system testing leaves whole categories of interaction and end-to-end defects undetected.

Worked Example: Tracing One Feature Through the Levels

For an online loan application: component testing verifies the interest-calculation function with isolated inputs (using a stub for the rates service); component integration testing verifies that the application module correctly calls the credit-check module and passes the applicant's data in the agreed structure; system testing runs the full "submit application → credit check → decision → notification" workflow against the requirements and also tests performance under load; system integration testing confirms the system correctly exchanges data with the external credit bureau's live API; and acceptance testing lets loan

officers (UAT) confirm the workflow supports their real business process while operations staff (OAT) confirm backups and monitoring are ready.

The same feature, evaluated five different ways, each with its own objective — the essence of test levels.