Test levels are a very practical model for structuring test activities. Each of these test level covers a different part of the software and the development context.
What are test levels?
The ISTQB defines test level as "A specific instantiation of a test process." This sounds quite abstract at first. Of course, there is a test process at each level. I don't think that does justice to the importance of test stages. For me, test stages are a core element of a test strategy. Why? The test levels differ massively from each other:
- You are looking at completely different areas of the software
- The testers have very different tasks depending on test level
- Test objectives, infrastructure, test data, framework conditions and scheduling differ greatly from each other
Each test level is an important piece of the puzzle for quality success and should not be neglected.
A synonym for test level is test level.
What are the test levels?
The classic levels are: unit testing, integration testing, system testing and acceptance testing. Integrations can take place at different levels, but they are tested differently. Therefore, there is still the distinction between component-integration testing and system-integration testing. The levels build logically on each other, 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 for themselves
- Component integration tests test the interaction of these units
- System tests test the integrated overall system for itself
- System integration tests test the interaction of several systems
- Acceptance tests test the complete system including interfaces in order to enable system acceptance
This classification makes sense in most projects, but of course it has to 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 put it next to the test levels, you can't deny a similarity. The test pyramid also distinguishes between different levels. In the original version there were unit testing, Service Test and UI Tests. In the meantime, there are also countless derivatives of these. 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 beginning 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.
Use the 7 success factors of software testing
Increase the efficiency of your software testing and the quality of its development.
Functionality | Efficiency | Usability | ... | |
|---|---|---|---|---|
Unit Testing | x | x | Cell | |
Components-integration testing | x | Cell | ||
System Testing | x | x | x | Cell |
... | Cell | Cell |
- The difference between the levels. It is a big difference whether I define and implement unit tests or 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 views of the application.
- The combination with the test types. Especially non-functional tests are often neglected. This can lead to massive problems. For example, performance tests are only performed towards the end of the project. These reveal architectural weaknesses. 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: 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 very high, a quick win for every project.