In artificial intelligence, metrics are like a compass and a barometer, in a way that they indicate whether the model is heading in the right direction and how reliable it is. Imagine you are watching an athlete. Some people evaluate their tThe test pyramid is familiar to all testers and QA professionals in the IT world. It has always been the backbone of the test hierarchy used to check software quality. In addition, it allows us to determine what tests are required at a given level of application advancement and how many there should be. Recently, however, a new term has appeared in the testing world, namely the Test Tower. So, what is the Test Pyramid and what is the Test Tower, what do they have in common and how do they differ, and which one should we choose for quality assurance and software testing in our project? And do we even have to choose between them?
Test Pyramid
The test pyramid is a graphical representation of test levels and their frequency of use. An additional aspect is the cost of tests, which can also be included in this pyramid. The aim of this concept is to optimize the time needed to perform tests as a whole. In agile methodology, changes are made to the code several times a day, so testing time should not take too long. Looking at the bottom of the pyramid, we can find:
- Unit tests — they are fast, and adding new ones will not negatively affect their execution time. However, their scope should be well thought out so as not to generate unnecessary tests in terms of quantity — even unit tests. Above all, these should be tests that check business logic in isolation from external components.
- Integration tests — these are used to check the integration of services or systems and whether they can communicate with each other. The cost of producing and maintaining these tests is generally slightly higher than for unit tests, but this does not have to be the case in every project.
- Acceptance tests — the purpose of these tests is to mimic the behavior of the end user. This is true for both manual and automated tests. The advantage of this type of testing over lower levels is its higher business value.
Test Tower
Unlike the pyramid, which always seeks to organize tests into a given pattern with its shape, the tower works differently. It shows that, depending on the needs of the project and the team, tests can be arranged differently, akin to the form of a tower. It can be slender and tall (highly automated) or massive with extensive foundations. Either way, the shape of the tower is more flexible and adaptable to the project rather than the pyramid.
Foundation — fast and repeatable tests. This is the basis of every tower. These tests are run after every change in the code and keep the entire system in check. These are unit tests, smoke tests and automated regression.
Tower core — communication. When a system consists of many microservices, communication becomes a problem. This is where contract tests — light, fast and effective — come into play. They allow you to check whether the services communicate with each other without having to run the entire heavy integration environment.
System layers — real interactions. At this level, you can see the true behavior of the application. This is where we perform component and integration tests. These tests are slower and more expensive, but necessary to perform and verify the application. At this stage, errors that could not be detected earlier (lower in the tower) are usually revealed.
Observation deck — performance and load testing. Here we also find E2E testing and functional testing in a BDD approach. Let’s call them tower windows. They provide a broader perspective and allow us to see how the system works as a whole, rather than at individual levels (floors).
Top of the tower — the part of tests that cannot be replaced by automated tests. Usability and accessibility tests, exploratory tests and acceptance tests can all be found here. By performing usability and accessibility tests we check whether the product is intuitive and tailored to the user. Exploratory tests show unexpected scenarios, while acceptance tests confirm the compliance of the final product with business requirements. These tests can be compared to guards on a tower. They are not needed all the time, they do not work hard all the time, but in key and difficult moments they are vital.
How to use the test tower?
It is recommended not to take the tower as gospel truth, something to be blindly copied without a proper analysis. It is worth looking at it as a way of thinking about testing in terms of value, not fashion. You can tailor tests in terms of value, taking into account that not everything has to be tested the same way in every project, even if we use the aforementioned tower. Keep in mind that testing is a dynamic and contextual process. However, it is worthwhile to remember to have strong foundations and consistent levels.
Choice — what is the test best option?
Is it necessary to choose and commit to one best and infallible test structure? In my opinion, no. Both the pyramid and the tower will have their supporters. Heck, even the same person may opt for the pyramid in one project and see the value in the tower in another, and build the application test scheme on it. It all depends on the needs of the project, the team, and the client. Our best choice will be openness and flexibility in selection and evaluation — because we never know what project or product we will be dealing with and which test model will be better at that time, and we should be guided by the fit with the team, project, client, and user needs, not personal preferences.
