The test-EiffelTower versus test-Pyramids
The more developers I teach about the testPyramid (as described by Mike Cohn in his book Succeeding with Agile) the more I think it should actually be a test-EiffelTower instead. Let me explain my reasoning.
The great pyramids are ancient marvels of engineering, but engineering which mankind still does not fully understand as we do not know how they where exactly build. On the other hand the construction and engineering of the Eiffel Tower is pretty well documented. The goal of test automation partly is that it describes how the product was constructed as a form of documentation. Therefor I think the Eiffel Tower is a better fit as tests should not be compared with unknowns like pyramids. Though this might be the least important part of my reasoning.
The lookout tower
Over time the testPyramid has been extended to have an eye of providence at the top to incorporate Agile testing practises like exploratory testing and as testers need to have an “all-seeing eye” to overview the product development. These additions make create sense.
The top of the Eiffel Tower already has a space for these practises as it was designed as a lookout tower from the start. A place where we as a team can overview the product we are creating. It was build using engineering practises to stand the test of time and it was delivered way ahead of schedule. It is around three times larger in height compared to the great pyramids. Giving you a better and broader overview from its lookout. Also it is illegal to climb pyramids as it is dangerous and brittle, not something we want our tests to be, or do we?
Spreading testing efforts
The test pyramid is often used as a guideline how-to split your testing efforts, but the structure itself does not have separate parts like the Eiffel tower does. With pyramids you get imaginary lines where as the Eiffel tower better matches my ideal split when looking at the volumes of it parts.
- The base: Unit-tests should cover ~75% of overall effort in test-coverage and time spend creating them.
- The middle : Integration tests should cover ~20%. (for example components 7%, integration 7%, and API 6%)
- The top: End-to-end UI testing should cover ~5%. Maybe one or two functional tests per feature is enough, just enough to make sure the feature is working and is build testable. Only add more tests when you find defects, but only on this level as a last resort.
- The lookout: Use time-boxed exploratory testing and code-review sessions to find gaps in your other testing efforts.
Compared to the traditional test pyramid (which has a 70/20/10% split) the Eiffel tower’s outlining better highlights that you need significantly less tests at the top. As it is becoming a thin line at the top that just needs to support your outlook hideout. It structure is designed in a way it can cary its weight, just as automated tests are needed to keep delivering features overtime in a constant pace. As they give you the room to refactor, maintain and extend your current product with confidence.
Although the test-EiffelTower is bit harder to draw with a little bit of practise this should not be holding you back. Hopefully you now also think the Eiffel tower is a much better fit to explain modern Agile test engineering. With a more modern example compared to ancient pyramids.
Please leave comments and questions I am very curious after your thoughts.
For more info about test pyramids and their practises try these references: