The four test levels and why their order matters

The four test levels are unit, integration, system and acceptance, and each one answers a different question: does the part work? do the parts fit together? does the whole product work? is this what the business asked for? They are not the same test in four sizes. They are four questions you cannot answer in the same place, and that is why the order in which you ask them changes how much each error costs you.

The ISTQB, the body of knowledge most widely used to certify testers, defines these levels as a deliberate sequence, not as a menu of options [1]. Each level assumes the previous one already gave its answer. When you skip one, you do not remove its question: you push it upward, where answering it costs more and arrives later.

01 · the four questionsWhat each level examines and why they differ

A test level is defined by the object it examines and by who does the examining. Moving up a level is not doing "the same thing but bigger": it is changing the question, the environment and, often, the person who judges the result.

Unit. It examines the smallest piece that makes sense to test in isolation, almost always a single function or method. The developer writes it, it runs in milliseconds and it touches neither the database nor the network. Its question is simple: given this input, does the function return the correct output? We cover this level in depth in the article on unit testing; here it is enough to remember that it is the foundation and the cheapest of them all.

Integration. It examines what happens when two or more units work together. Each part can be flawless on its own and the whole still fails: a date format one side sends and the other does not understand, an error swallowed in silence, a contract wrongly assumed between modules. Unit testing never sees that error because, by definition, it looks at a single part. The detail of when this level pays off is in the article on integration testing.

System. It examines the complete product, already assembled, running as a single thing in an environment close to the real one. Here you test the whole end to end flow and also what no individual part guarantees: that the system is fast, secure and holds up under load. It is the first level where the object under test is "the software", not "a piece of software".

Acceptance. It examines whether the system serves what the business or the user asked for. It changes the question at its root: it is no longer "is it well built?" but "did we build the right thing?". The customer, the product owner or the end user judges it, not the technical team. A system can pass the three previous levels without a single defect and still fail here, because it solved the wrong problem.

The first three levels ask whether the software is well built. The fourth asks whether it was the right software. It is not the same question.

02 · why the order mattersEvery error has a level where catching it costs less

There is a rule that has echoed through software engineering since the seventies: the cost of fixing a defect grows as it moves through the phases of development. An error caught by a unit test is corrected in minutes, often before it even leaves the editor. The same error caught in acceptance, or worse, in production, can cost orders of magnitude more, because you have to trace it through all the assembled parts and sometimes redo decisions already made.

The order of the levels is not bureaucracy: it is a strategy for placing each net as low as possible. Unit testing catches logic errors inside a function. Integration catches misunderstandings between modules. System testing catches failures that only appear once everything is assembled. Acceptance catches the costliest error of all: having built the wrong thing. Each net catches what the one below cannot see, and lets through as little as possible to the next.

That is why skipping a level does not save time. If you skip integration, contract errors between modules do not vanish: they resurface in system testing, mixed with twenty other problems and far harder to isolate. The work you did not do below you pay for above, with interest.

The work you do not do at the level below does not disappear. It climbs a level and becomes more expensive to find.

03 · how they fit into your suiteFrom the model to practice without turning dogmatic

The four levels describe questions that must be answered, but they do not dictate how many tests of each you should have. That proportion is governed by another figure: the test pyramid, which recommends many cheap and fast tests at the bottom and few expensive and slow ones at the top. If the levels are the questions, the pyramid is the budget with which you answer them. We treat it separately in the article on the test pyramid.

In practice, the levels do not always run in strict sequence, nor does the same team execute them. In a modern flow, unit tests and many integration tests run automatically on every code change; system tests, in a preproduction environment; and acceptance tests, with the business involved before giving the green light. What matters is not the ceremony, but that none of the four questions goes unanswered before the user answers it for you.

Seen this way, the four levels stop looking like a bureaucratic hierarchy and become what they are: four filters ordered from small to large and from technical to human. Unit for the part, integration for the fit, system for the whole, acceptance for the purpose. Skipping one does not erase its question. It only decides who will answer it, when and for how much money. And almost always, the one who ends up answering it is the user, at the worst possible moment.