Test AutomationTest pyramid
Testing on a stable foundation
Modern software is not a monolith, but a complex system consisting of specialized modules. The surface of a website (“front end”) communicates with internal systems (“back end”), which in turn have various interfaces to databases or other software systems.
So it makes sense to test each area separately before testing the entire software from the user's point of view. This is usually done in three test levels:
Contact
Why a test pyramid?
The shape of the pyramid is to be understood in several ways:
- Each level builds on the previous level.
- The basis is formed by a large number of tests that can be carried out quickly in the unit test.
- The top is a few tests in the system test that involve a lot of testing.
By the way: If you look at the cost side of errors, you get an inverted pyramid. Errors that are only found in the system test often entail extensive changes and are more expensive.
Unit test
Unit tests form the foundation of the test pyramid. In this test level, the individual components of a system are tested independently. All interfaces to the other components are simulated so that error situations can also be checked.
The aim of the tests is to identify at an early stage whether there have been any unexpected changes in the behavior of a software. Therefore, unit tests are almost always run as part of a CI/CD pipeline with each build.
Since the interaction with other interfaces is simulated, the tests can be carried out in a very short time. Our experience is: The sum of the unit tests should not take longer than 10 minutes.
Development-related tools such as JUnit, TestNG or Mocha are used here.
Integration test
When the individually tested components are combined to form the overall system, the integration test follows. The following questions, among others, are to be found in this test level:
- Are the data formats compatible between two components?
- How does component 1 behave if the data of component 2 are provided with a delay?
- Can component 1 misuse, manipulate or destroy the data from component 2?
Existing frameworks from unit tests are supplemented by tools such as REST Assured. The focus is now on the quality features "reliability", "compatibility" and "security".
System test
After all components of the software have been tested and their interfaces have also been checked, the so-called "system test" follows. Now the software is viewed exclusively as a "black box". The following tests, among others, can be found at this test level:
- Tests of the user interface, automated or manual through reviews
- Use case-based tests across multiple systems (end-to-end tests), for example with access to participating systems that are only available for testing to a limited extent
A test environment that is close to the later productive system is often used here.
Tools such as Micro Focus UFT or Selenium are used here.
It is advisable to run the system test continuously as part of the regression test in CI/CD pipelines.
Manual testing
Manual tests are essential when it comes to the following types of tests:
- User acceptance tests, i.e. tests with end users
- Acceptance tests of a software for the final acceptance of a software development
- Smoke tests when rolling out to systems that are difficult to automate in the test or productive environment
Manual tests are often found at the system test level, but they can also be used for component or integration tests.
Contact us so that we can develop the right test concept for you!
Any questions?
We are happy to provide you with know-how, specific support services and associated license and support offers.
