Figure 3 – The Test Pyramid includes different types of tests
In theory, it sounds like a simple plan: make your tests easy to run and the test results easy to understand. In practice, however, this can be a challenge. Historically, different flavors of tests are built and maintained by different engineers, often using different tools:
- Unit tests are used to prove correctness of the low-level building blocks of an application
- Service & API layer tests are built to prove the correct functioning of complete sub-systems
- Human-machine interface tests (HMI) / functional tests are built to prove correctness from an end-user point of view
When tests are partitioned this way, each flavor of tests is owned and maintained by a different group of engineers rather than being shared across all members of the development team. In fact, in most organizations, it is probably impossible for a QA engineer to run a developer test or a developer to run a system test.
In order to improve quality, it should be possible for any member of the development team to run any test at any time on any version of the application.
The key to enabling this workflow is a common test collaboration platform, which captures all tests, along with their preconditions and expected results. Engineers should be able to run a single test, or all tests with the “click of a button”. In addition, it is essential that engineers are able to quickly debug failing tests.
Additional information can be found in the following document: