Is Your Testing Pyramid Actually a Blob?
Every QA team I have talked to says they follow the testing pyramid. Then I open their codebase and find a shape no architecture textbook ever drew. If you are a QA engineer, an SDET, or a QA lead, this matters for one reason: the testing pyramid is the difference between a regression suite that finishes in eight minutes and one that takes forty-five, fails for no reason, and gets ignored by half your team. The video above walks through the audit, and below is the written version with why the shape is math, the three layers you are probably missing, and a five-minute test that tells you if your pyramid is real or imaginary.
The shape is math, not opinion
The pyramid is dictated by speed and stability, so the cheap, deterministic tests belong at the bottom.
Mike Cohn introduced the pyramid in 2009 in Succeeding with Agile: a wide base of unit tests, a middle of integration tests, and a narrow top of end-to-end tests. People treat this as a style choice. It is not. Unit tests run in milliseconds, integration tests cross real boundaries and cost tens to hundreds of milliseconds, and end-to-end tests drive real browsers and cost seconds each.
If a regression suite has to fit a CI budget, and every suite does, the volume belongs where it is cheap. I explain this in the video. There is a second reason too: stability. Unit tests are deterministic, while end-to-end tests fail for reasons unrelated to your code, so you want the bulk of your trust at the bottom.
The three layers you are missing
Each layer catches a different class of bug, and skipping one leaves a blind spot.
Layer one, unit tests, exercises one function in isolation with dependencies mocked. It catches bad logic, wrong math, forgotten edge cases, and null handling. What it cannot catch is how your function behaves wired to the real system.
Layer two, integration tests, takes the mocks off and hits a real database or a real service. It catches wiring problems, schema mismatches, auth bugs, and serialization issues at the boundary where your code meets someone else’s. Layer three, end-to-end tests, drives the system the way a user would and catches the bug hiding in the seams, like a button wired to the wrong route. What it does poorly is pinpoint the failure. When it breaks, you know something is wrong but not what.
The five-minute test
Pull three numbers, counts, runtimes, and flake rate, and the true shape of your suite reveals itself.
Here is the audit I ran. First, count the tests in each layer. If your end-to-end tests outnumber your units, you are building an ice cream cone, not a pyramid, and it will melt. Second, measure total runtime per layer. A unit suite should finish under a minute, integration under five, and if end-to-end runs over fifteen you have a real problem.
Third, measure flake rate on green code. Run the suite three times without changing anything and count how many tests fail in at least one run. I measured this on real suites, and if the rate is over 2 percent, the suite is a liar you cannot trust. A healthy pyramid sits near 70 percent unit, 20 percent integration, and 10 percent end-to-end. The ratios vary by codebase. The shape does not.
Three things to do Monday morning
Audit the shape, push tests down a layer, and set a CI budget you actively defend.
First, pull the three numbers, put them in a doc, and share it. The doc itself becomes the conversation. Second, for the next three weeks, every time someone writes an end-to-end test, ask whether it could be an integration test instead. Most can, and most are not, because writing higher is easier in the moment.
Third, set a CI budget, twenty minutes or fifteen or ten, put it on a dashboard, and when duration crosses the line you optimize or remove a test. What I learned is that the pyramid is a shape you maintain, not one you achieve. Code grows, test count grows, and the shape stays only because someone, usually QA, defends it.
The takeaway
Most pipeline pain traces back to a pyramid that is not actually a pyramid. The shape is math: cheap deterministic unit tests at the base, integration in the middle, slow end-to-end at the narrow top. Audit yours with three numbers, counts, runtimes, and flake rate, and if it is upside down you are running an ice cream cone. Push tests down, defend a CI budget, and treat the pyramid as a shape you maintain forever.
Watch the full audit in my video on the testing pyramid, and I walk through the five-minute test in the video. I also show what an upside-down suite looks like in the video. Here is my question for the comments: what does the shape of your suite look like right now? Pull the numbers and tell me. Subscribe for more, and methodology over luck.
