Test Levels

Why it matters

Testing everything at the end through the user interface makes defects slow to find and hard to locate: a wrong checkout total could come from a rounding function, an interface between services, a configuration or an external provider. Each level looks at a defined object with its own test basis, so a failure points to a smaller area and many defects are found earlier, closer to their cause — the early testing principle in practice.

Levels also expose gaps and duplication: if nobody owns system integration testing, customers are the first to test the payment interface. For a tester, the levels tell you which documents to ask for, which environment you need and which defects to expect.

What a test level is

In the V-model lesson each development level was paired with a test level. ISTQB calls each test level an instance of the test process: the test activities, from planning to completion, happen at every level. In sequential models the exit criteria of one level are often part of the entry criteria for the next. In some iterative models this may not apply: development activities can span several levels, levels can overlap in time, and one sprint can include work at every level.

Levels are not test types. A test type groups test activities by what they check or how the tests are derived: functional and non-functional testing look at different quality characteristics, while black-box testing derives tests from the specification and white-box testing from the internal structure. Most types can be performed at every level: a performance test can measure one database query or the whole checkout. ISTQB separates the levels by these attributes:

• Test object: what is tested, from a function up to an interface with another system.
• Test objectives: what the level should show.
• Test basis: what the tests are derived from, such as a design or user stories.
• Defects and failures: what the level is best placed to find.
• Approach and responsibilities: techniques, environment and who does the work.

The five test levels in CTFL v4.0

CTFL v4.0 defines the five levels and the attributes above; the test basis and defects below are the typical ones, as listed in the earlier (2018) syllabus and seen in practice, and your project’s documents decide the real basis. ISTQB also calls component testing unit testing, and component integration testing unit integration testing.

• Component testing: one function, class or module in isolation, often run with a unit test framework; to isolate it, the parts it depends on can be replaced by test doubles, simple stand-ins such as stubs and mocks. Basis: detailed design, code. Typical defects: wrong logic or calculations.
• Component integration testing: the interfaces and interactions between components, shaped by the integration strategy: bottom-up (lowest components first), top-down (from the top, with stubs for missing parts) or big-bang (everything at once). Basis: software design, API specifications. Typical defects: interface mismatches, missing or wrongly encoded data, wrong assumptions about the units of data passed between components.
• System testing: the behaviour of the whole system, including end-to-end tasks and non-functional characteristics, in a representative test environment. Basis: requirements, user stories, use cases. Typical defects: behaviour that contradicts the requirements, tasks that cannot be completed, slow responses.
• System integration testing: the interfaces with external systems and services, such as a payment gateway or an SMS provider, in an environment close to production. Basis: interface agreements, external API documentation. Typical defects: inconsistent messages, unhandled timeouts, wrong assumptions about exchanged data.
• Acceptance testing: validation that the system meets the users’ business needs and is ready for deployment. Main forms: user acceptance testing (UAT), operational acceptance testing, contractual and regulatory acceptance testing, alpha testing and beta testing. Basis: business processes, acceptance criteria, contracts, regulations. Typical defects: workflows that do not fit the business, wrong business rules, unmet contractual or regulatory requirements.

Try it: API Contract Validator Try it: Mock API Response Generator

Who usually performs each level

These are typical responsibilities, not fixed rules; in agile teams testers and developers often share the work. What should not blur is ownership: every level in the test plan needs a named owner, and a tester still reviews the levels they do not own, for example by asking what the integration tests replace with stubs.

• Component and component integration testing: usually developers, automated in their own environment and in continuous integration (CI).
• System testing: testers, often an independent test team or the testers in the delivery team.
• System integration testing: generally testers, together with the owners of the other systems.
• Acceptance testing: ideally the intended users — business users, customers, the product owner, or operations staff for operational acceptance. Testers often prepare and record; the business decides.

Try it: Acceptance Criteria Generator

Worked example: promo codes across five levels

An online store in Saudi Arabia adds promo codes. The cart service calls a promotions service, and payment goes through an external gateway. Each bullet takes one level: a test at that level and the defect it finds first. Note that the halalas-versus-riyals defect is invisible to the component tests on either side, and the acceptance gap is invisible to every test derived from the story.

• Component: 10% off 199.99 SAR should be 20.00, but the function cuts 19.999 to 19.99 instead of rounding it.
• Component integration: the cart sends 19999 (halalas) while the promotions service expects 199.99 (riyals); each passed its own tests.
• System: in the full checkout, VAT is calculated before the discount, so the customer pays too much.
• System integration: through the gateway’s sandbox, the gateway receives the original amount, and a timeout leaves the order "pending" with no message.
• Acceptance: the marketing team finds that a customer can reuse a code again and again. The story never said "once per customer", so every level passed — a validation finding, as in the lesson on verification and validation.

Story PROMO-12: Promo codes at checkout
As a customer, I want to enter a promo code so that I pay less.

AC1  A valid code gives 10% off the items subtotal.
AC2  VAT (15%) is calculated on the subtotal after the discount.
AC3  The delivery fee is not discounted.
AC4  Amounts are rounded to 2 decimal places (nearest halala).
AC5  An expired or unknown code shows "This code is not valid".

Try it: Requirements → Test Cases Try it: User Story → Test Scenarios

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.