Refactoring your E2E tests from an ice-cone to a pyramid

In our daily experience in working with customers, we notice that the test pyramide is still not well understood and applied correctly. If you ask teams about the test pyramid you will either get different opinions and definitions or a lot of excuses for not applying it in their software development lifecycle. There 1.000 reasons for resistance against unit testing from developers especially the believe that UI, E2E and system tests are more effective and efficient then unit tests.

On the other side testers and QA engineers are not trusting the developers to test the right thing and they fear that the functionality is not tested suffiently. A constant communication and close collaboration between the testers and developers is crucial for distributing the test cases on the individual testing levels. In our talk we want to demonstrate the architecture, the code and the E2E tests of a typical application leading to an test automation ice cone.

We are going to explain the disadvantages of this testing strategy by measuring the tests' runtime, the duplication of the coverage and complexity of the test scripts. During our demonstration we are going to refactor the test automation code and from the highest testing level towards its level below. After each refatoring step we will measure the differences and analyze the distribution again. The refactoring will be repeated until all tests are distributed correctly in the testing pyramid.

Finally we will explain the benefits of the achieved solution compared to the starting point of our refactoring journey.