I really appreciate the concept of the software test pyramid that emphasizes having a large number of low-level unit tests, fewer integration tests, and
even fewer ent-to-end tests.
Despite the advantages of a this approach, software projects often reveal defects that only become apparent when testing interactions between multiple components.
But stakeholders frequently underestimate the necessity of system tests, assuming that a robust unit test base ensures software reliability.
To better illustrate the role of system testing, I prefer the Temple Pyramid Model. This model builds upon the original test pyramid but introduces a temple structure at the top, symbolizing system tests as a crucial component of software quality assurance.
Surprise! The testing pyramid is not always the best
It really depends on your architecture for example the Testing Trophy might be way more your thing depending on you choice of tech.
I think this question really depends on what tech and architecture you are using. So there is no “right” answer to this question at the moment. Perhaps you are talking about spotify? Then the Testing Honeycomb might be better: Testing of Microservices - Spotify Engineering : Spotify Engineering
So it really all depends on architecture. There is no “best”
PS: I’m not sure what “the temple pyramid model” is? Is that just the testing pyramid? (can’t find it on google either)
The Tempe pyramid is simply a pyramid with a temple top that is meant to represent system testing.
It aims to change the mindset of stakeholders and reinforce that while unit testing provides a solid foundation, system testing is essential to ensure the reliability of software in real-world applications
Is think there is no such image on the internet. The idea of using a temple pyramid was born in my head to give more emphasis to the system test. But in the end it would be your picture with the difference that for the end-to-end tests it is not a peak but a rectangle.
Now I don’t see any model as the silver bullet solution to any test approach. Otherwise there wouldn’t be any need for continuous improvement. However, they’re all born trying to solve a problem.
So I find it interesting to research and see different perspectives on these models and then taking a step back and ask “do we have similar problems?”. The one thing this model and that presentation taught me is that our QA team don’t have enough visibility or understanding of Unit Tests and dev to our system tests. We respect each others work and perspectives but we’re missing an opportunity to make all the test levels interconnected and understood. So that was my take on it.
It tends to bother me that it gets incorrectly called a test pyramid rather than an automation pyramid.
I still use it as a soft discussion idea, consider where in the stack it makes sense to automate coverage of a specific risk.
I think before it was hard guideline discussion only to counter the model where developers were offloading the idea of automation onto testers who at that point often only new about the hardest layer to automate at the UI.
If that still exists and companies are starting their first ventures into automation thinking only of the UI and testers doing the automation then for me a lot of the thinking behind it still holds true.
It remains more important to me to recognise its not a testing model because that can happen and it then gets missused by teams who drop out some really important testing by following a model that is specifically talking about automation. Well that and that it is just a model and there are often better suited ones depending on individual project needs and goals.
(can’t find it on google either)
