Test Levels or Test Stages - Richard Seidl

Test levels are a very practical model for structuring test activities. Each of these test levels covers a different part of the software and the development context.

What are test levels?

The ISTQB defines a test level as “A specific instantiation of a test process.” This sounds quite abstract at first. Of course there is a test process at every level. I don’t think that does justice to the importance of test levels. For me, test levels are a core element of a test strategy. Why? The test levels differ massively from one another:

• They look at completely different areas of the software
• The testers have completely different tasks for each test level
• Test objectives, infrastructure, test data, framework conditions and scheduling differ greatly from one another

Each test stage is an important piece of the puzzle for quality success and should not be neglected.

A synonym for test level is test level.

What test levels are there?

The classic stages are: Unit test, integration test, system test and acceptance test. Integrations can take place at different levels, but they are tested differently. This is why there is a distinction between component integration testing and system integration testing. The levels build on each other logically, which is also the basis for the development of this model:

• Unit tests (or module or component tests) test the smallest units in the software individually
• Component integration tests test the interaction of these units
• System tests test the integrated overall system on its own
• System integration tests test the interaction of several systems
• Acceptance tests (or acceptance tests) test the complete system including interfaces to enable system acceptance

This division makes sense in most projects, but must of course be adapted to the circumstances.

Difference between test levels and the test pyramid

In agile testing, we often use a model by Mike Cohn: the test pyramid. If you place it next to the test levels, you cannot deny a similarity. The test pyramid also distinguishes between different levels. In the original version, there were unit tests, service tests and UI tests. In the meantime, there are also countless derivatives. The test pyramid focuses more on the aspect of test automation:

• Lower test levels have more test cases than higher test levels
• Lower test levels are faster than the higher ones
• The degree of integration increases towards the higher test levels.

I know developers who use both models and sometimes combine them. Like the test levels, the test pyramid is a concept with a few drawers. In everyday life, these models have to be questioned again and again.

In practice

For me, test levels are a cornerstone of the test strategy. At the start of a project, I always consider them in combination with the test types. This results in a matrix from which a large part of the test activities can be derived. This is an important point of reference for both classic and agile software development.

There are always two “aha” moments for everyone involved:

1. the difference between the levels. There is a big difference between defining and implementing unit tests and system tests. Even if these are developed in the same framework, such as JUnit. The tool is the same, but the test cases could not be more different and cover completely different perspectives on the application.
2. the combination with the test types. Non-functional tests in particular are often neglected. This can lead to massive problems. For example: performance tests are only carried out towards the end of the project. These reveal weaknesses in the architecture. Now it costs a lot of money and time to solve these structural problems. The combination with the test levels creates awareness for this at an early stage. What could robustness at unit test level look like, for example? Efficiency in integration tests? Reliability in system tests?

Test levels bring structure and clarity to software tests in everyday project work. I experience this time and time again. Another advantage is that this clarity can be achieved quickly. An overview of the test levels and test types relevant to the project can be created in an initial workshop. The added value of this is huge, a quick win for every project.