The test pyramid is one of the most cited models in QA, and one of the most misapplied. The shape isn't a goal in itself, it's a translation of where risk typically sits.
Many teams treat the shape as a goal in itself: lots of unit tests, a bit fewer integration tests, and as few end-to-end tests as possible, full stop.
But the shape isn't a goal. It's a translation of where risk typically sits in a classic architecture. Shift that architecture, and the risk shifts with it, and your test strategy should follow.
Three situations where deviating is the right call
API-first architecture
Contract and API integration tests matter more because a lot of risk sits in the collaboration between services. That shifts the balance, sometimes deliberately, toward more integration tests.
Legacy code without tests
Start with a handful of end-to-end or characterisation tests as a safety net. Then add unit tests as you refactor. Reversing the classic order is the safer route here.
UI-heavy applications
With complex front-end logic, think canvas or drag-and-drop interactions, a larger share of the test strategy rightly shifts toward component and UI tests.
The rule of thumb
The test pyramid remains a good starting point, precisely because it captures a real assumption: in a classic, layered architecture, most of the risk sits at the lowest level, so that's where you test the most. The problem only starts when teams keep following that shape after their architecture has long since changed.
So don't ask yourself "are we still following the pyramid", ask "where does our risk sit today, and does our test strategy cover it". Sometimes the answer is exactly the classic shape. Sometimes not. Both are fine, as long as it's a deliberate choice and not a habit nobody questions anymore.
Sounds familiar?
We'll review your test approach and tell you honestly where the gains are. And where they aren't.
Book a call