2.3 Test Levels: Component Through Acceptance
Key Takeaways
- A test level is a group of test activities organized and managed together with specific objectives.
- Component testing focuses on individual units or components, often with stubs, drivers, or mocks.
- Integration testing focuses on interactions between components, systems, or external services.
- System testing evaluates the complete integrated system against requirements and risks.
- Acceptance testing evaluates whether the system is acceptable for users, customers, operations, contracts, or regulation.
Why Levels Exist
Test levels divide testing by objective and scope. They help a team find defects close to where they are introduced while still evaluating the integrated product from user and stakeholder viewpoints. The main CTFL levels are component testing, integration testing, system testing, and acceptance testing.
Component testing checks individual units, modules, classes, services, or other low-level components. It is often performed by developers and may use stubs, drivers, mocks, or simulators to isolate the component. Typical defects include incorrect logic, boundary handling errors, and local data handling problems.
Integration testing evaluates interactions. Component integration testing checks interfaces between components. System integration testing checks interactions between systems, external services, databases, hardware, APIs, or third-party products. Typical defects include interface mismatches, wrong data formats, timing issues, and communication failures.
| Level | Main test object | Common objective |
|---|---|---|
| Component | A unit, module, class, or service | Show the component works in isolation |
| Integration | Interfaces and interactions | Find defects in communication and cooperation |
| System | Complete integrated system | Evaluate end-to-end behavior against requirements |
| Acceptance | Product in stakeholder context | Decide whether the system is acceptable for use |
System testing examines the complete integrated system. It may include functional behavior, non-functional quality characteristics, workflows, business rules, error handling, and end-to-end scenarios. The test basis can include system requirements, risk analysis, user stories, regulations, and design documents.
Acceptance testing asks whether the product is acceptable. User acceptance testing focuses on users and business processes. Operational acceptance testing focuses on operational readiness, such as backup, restore, monitoring, deployment, and support procedures. Contractual or regulatory acceptance testing checks agreed or mandated criteria.
The same test type can appear at multiple levels. Performance can be checked at component, integration, system, or acceptance level. Functional behavior can be checked at every level. Do not confuse level with type. Level is about where and why testing is organized. Type is about the quality objective being evaluated.
A common exam trap is to label every user-facing test as acceptance testing. If the test team evaluates the complete system against system requirements before business acceptance, that is system testing. If users or representatives decide whether it supports business use, that is acceptance testing.
When answering level questions, identify the test object and objective. A single function or class points to component. An interface or interaction points to integration. The complete product against specified requirements points to system. Business, operational, contractual, or regulatory acceptability points to acceptance.
A team tests whether two services exchange customer status updates in the correct format. Which test level is most directly involved?
Which statements correctly describe CTFL test levels?
Select all that apply