I recently asked a question via the Ministry of Testing Twitter account that Iâd seen pop up somewhere else. I noted the question down at the time but forgot to note where it was originally asked 
Itâs the kind of question that I think should also be asked here on The Club as we can give longer-form responses to it/have a more detailed discussion about it.
Do you think weâre beyond the testing pyramid?
Gregory and Crispin (2014) said that for Agile there should really be another layer above the pyramid called âManual / Exploratoryâ
One of the things often misinterpreted in the pyramid is that itâs not created for manual testing. Itâs a test automation pyramid. So adding a manual/exploratory layer makes it a bit weird.
Looking at the responses on Twitter, I see a lot of people talking about the Test Honeycomb. I donât think thatâs the golden egg either. Itâs basically just the same as the pyramid, just in another form and with some other names. The concept remains the same. The pyramid was never meant in a way that the bottom layer should have the most tests. Itâs just an assumption a lot of people make.
Iâll need to think about my own answer, just wanted to share this already.
The problem with the Test Pyramid is that it basically talks about automated checking
Which is just a very small part of testing
The Round Earth model seems to give a more comprehensive explanation.
Itâs beginning to look like there are probably as many definitions of testing as there are people whoâve written about it.
My own âsuper strictâ definition comes from my time studying formal methods (a very long time ago!). The spec goes in at one end, software is developed, and testing attempts to âproveâ the spec by reconstructing it from what the software does and how it does it. Of course, thatâs not exactly agile or very efficient. Certainly not pragmatic! 
My gripes with the TPâŚ
Iâm concerned that a lot of places it is used/referenced donât really understand the real value of testing
Maybe it should be rebranded as just focused on automation. Or it could be turned into an actual pyramid with other triangles too 
Iâm also wondering about the specifics of the layers - tooling is getting more and more advanced now, particularly with the UI level. Iâm not sure UI-level automation is the anti-pattern to the same extent it was a couple of years ago.
No, it is a useful resource and a good foundation - maybe a refresher version, but we can never be beyond it, or we would lose sight of the basic foundations - just my viewâŚ
The origin of the pyramid is actually that it should be used for Test Automation only. Itâs just that people started âabusingâ it by adding Exploratory to it. So itâs just a case of having people use it the way it should be used.
The test pyramid stills being useful, of course, but it shouldnât be considered a rule. Itâs just a model that helps addressing a problem under a certain context, but everything (or almost everything) is context dependant, so this model could fit in some conditions and cause issues in others.
Regarding the other topic on this thread, I donât think the test pyramid is incomplete. Its purpose is simple: helping you decide where to focus efforts when adding automated tests (or checks) for something. Anything else is out of the scope of this model and reducing your testing strategy to just this pyramid would be a mistake in my opinion, instead you should consider adding this pyramid to your testing strategy (if it fits).
I interview people who apply to work at my company. One of the questions we ask is to explain the test pyramid. I get different answers all the time. So I guess the question you are asking depends on how you define the test pyramid.
Just in the response from so far I see different people saving different things. Some believe the test pyramid is just about automated testing. Others give different levels. Rarely do I see people talk about why I believe the test pyramid is useful.
Is it about automation? I donât think so. I started my testing career in 1998. There wasnât a lot of agile at that time. Almost everything was waterfall. The software developers in my company started adopting agile software development. There was still a throw it over the wall attitude for testing and QA.
Iâd get story 1. Iâd test it. Iâd get story 2. Iâd test story 1 and 2. Iâd get story 3. Iâd test story 1, 2 and 3. After a while I could not test everything. So we started prioritizing stories. The most important stories would get tested first. Out of 500, the QA team might test the top 300 stories but the other 200 stories wouldnât get tested before we got another release from development. The solution I, and many others, came up with was to automate everything. I was automating everything at the end and maintaining the test suite was difficult. But automating a lot of the stories meant we didnât have to manually test everything. Automation helped with regression testing. No pyramid involved.
Always wanting to be efficient, I thought about how can I prioritize my testing? Are their tests I donât need to do? WAIT. There are unit tests. I might have a test that could fail for 7 reasons. I had to gather enough information in the automation to know why it failed. But 4 of those reasons would have been caught at the unit level. So I really only had to code for the remaining 3 reasons the test would fail.
Even better, could I test two classes together and eliminate more reasons my system level test might fail? I could create 2 integration tests. Now there was only one reason my system level test would fail.
This made automating the tests easier. This made debugging failures easier. This made some defects found sooner (fail fast). Then I found out about Mike Cohn and the âtest pyramidâ. This basically put into words what I had discovered. The simpler the test, the easier it was to maintain (you can find many pictures of the test pyramid that talk about cost and how it goes up as you go up the pyramid). Additionally, if you had a system level test and there were a dozen reasons it could fail then it was time consuming to figure out why. But if you had unit level, integration level, contract level, etc. then you could spread out where the failures occurred.
If you test things in sequence, then you KNOW defects will be found at the unit level before they make it to the higher levels. Defects will be caught at the integration level before they make it to the higher levels. But if you start testing things in parallel or not in a sequential order then you, in my opinion, defeat the purpose of the test pyramid.
So to me, we automate so we can fail fast. The test pyramid is more about making things easier to maintain and debug.
Exploratory testing is not a separate discussion for automation, because using the tools for automation in exploring will have much benefits, so if you need UI and API tools (orso) to help you with exploring and learning, that is part of the automation pyramid too.
While I do certainly agree that the bulk of the testing pyramid is indeed about automation, that doesnât mean that exploration (in whatever way, shape or form) doesnât have a place in it. It has a place, and a very prominent one. Itâs just not stated explicitly and itâs definitely not a layer on top in my opinion.
It comes down to how you design your tests and how you come to that. If, for whatever reason, I decide to write an automated test for some feature, I always start with collecting as much information as possible. I sit down with the dev whoâs writing (or wrote) the feature, I look at the docs (if itâs documented), I fire up the application and look under the hood and try to see how all the moving parts are connected, I look at the ticket(s), etc. One might say that I start exploringâŚ
Now, Iâm going to need all that information so I can create a fast, reliable and meaningful test. And while the outcome of all my actions might come to fruition through code and automation, a large part of getting there comes through exploration. And itâs actually during this exploration phase youâll encounter most of the bugs and inconsistencies. The automated test that comes after it just makes sure that it wonât happen again. And it doesnât matter on which layer I want my tests to be. Depending on the test and the outcome we aim for, the test resides somewhere in the pyramid.
So while there are many things that might be wrong with the testing pyramid, I donât think it being âonlyâ about automation or not including exploration is actually true.
Really like that round earth model.
To me the thing is these are âjustâ models and are about ways of categorising your testing at a high level. Basically IMHO theyâre guides that if youâre doing something way out of line with what they show then itâs worth (re)evaluating your approach.
One thing my career has taught me is for every rule thereâs an exception. However the rules (or in this case models) are useful for informing our thinking.
I think thatâs fair.
The problem I see with the pyramid, I think, is that itâs so common now that itâs seen as The Way to organise automation (and sometimes the entirety of testing itself).
Here we talk about fat or distorted pyramids but yeah I still find it useful for communicating.
You still want to avoid all tests are ui/e2e tests or even all test duplicate each other.
Not at all, is a very valid and simple model that still make sense for test automation. And that is its purpose.
I can understand people having issues with it not being usable to define their test strategy, a test strategy is much more than test automation, and this model is not fit for that, and it was never meant to.
Itâs telling something very simple: Have more fast and cheap tests than long and expensive ones. As long as they are providing value at all. You can add more layers to it, if it makes sense for you, but thatâs the whole point. In any other way it means that youâre having a slower and more expensive feedback than its probably optimal for a steady development.
But of course this is just a model, an abstraction, and it depends on its context to be valid or useful.
For all test related people it would imho be helpful to come beyond it. Seeing it as ONE model, not THE model.
So far I still see many people arenât.
" It was never a pyramid. It is in fact an iceberg" 
https://mrslavchev.com/2018/05/31/hindsight-lessons-about-automation-models-of-automation/
I find this two paragraphs very helpful: