The test pyramid, in plain English.

You may know the feeling. Something gets changed in your system, and a week later it turns out that something else has broken in the meantime, something that had worked without any problems for months. As a result, every new change feels like a gamble, and a release becomes something to dread rather than look forward to.

That is usually not bad luck, nor a matter of sloppy people. It is a symptom of where the testing happens. And that happens to be something you can judge, even if you don't write tests yourself.

There is a handy image for this: the test pyramidThe test pyramid is a rule of thumb for testing software: many small, fast and automated tests at the bottom, and fewer and fewer large, slow tests the higher you go.. Picture a pyramid with three layers. At the bottom, broad and solid, are lots of small checks that each examine a small piece of the software. They run automatically and in a few seconds, so they run again with every change. In the middle are fewer but larger checks that verify whether the components work well together. At the top, in the narrow tip, is a handful of checks that go through the whole application the way a user would. Those are valuable, but slow and fragile, so you deliberately keep few of them.

The shape is the whole point: broad and cheap at the bottom, narrow and expensive at the top. Some teams accidentally turn the pyramid upside down. They barely automate anything and mostly check at the end, by clicking through everything by hand just before a release. That wobbly arrangement is mockingly called the ice-cream cone: a little solidity at the bottom and a big, heavy scoop on top. It is slow, it breaks easily, and it misses precisely the bugs that nobody happened to click on.

Why testing at the bottom pays off so well isn't a matter of opinion, by the way. It's the same reasoning as Boehm's lawBoehm's law says that an error becomes more expensive the later you discover and fix it, and that the cost rises exponentially.: the later you find a bug, the more expensive it is to fix, and the cost rises quickly. A bug that a small automated check spots as the code is being written costs almost nothing. The same bug, surfacing only once it reaches your customers, costs many times more, plus the trust you lose for a while.

What does that mean for you in practice? You don't have to write or read a single test. You just need to ask the right question of whoever builds or maintains your software: how do you test, and does it happen automatically with every change or only by hand at the end? The answer tells you more than you might think. A team that calmly replies that most checks run automatically gives you a very different outlook from a team that tells you they spend a few days checking everything manually before each release.

And if you want to dig deeper, you can recognise a healthy approach by the fact that releasing a new version is routine rather than an event. Where the pyramid is the right way up, people are willing to make changes, because they find out straight away if something goes wrong. Where it is upside down, as little as possible gets touched for fear of breaking something, and that very caution makes a system more expensive and more rigid over time.

So you don't need to become a tester to benefit from this. You only need to know that the shape of the pyramid exists, and to ask every now and then whether yours is still standing the right way up.