QA Is Bigger Than the Build

For a long time, my definition of quality assurance was simple. You take an application, you check it against the specification, and you confirm it does what a user would expect to see. If the buttons worked and the screens matched the design, the job was done. It is a reasonable place to start. It is also a tiny slice of the real thing.

Years ago I came across an interactive piece called The Scale of the Universe, built by Cary Huang. You start at human scale and zoom outward, past planets and stars and galaxies, then inward, past cells and atoms, down to the smallest things we have names for. By the time you reach either end, you feel something humbling, how small we are, and how improbably specific our little slice of the middle is.

That stuck with me, and it quietly became how I think about my work. To do QA well, you have to zoom all the way in, close enough to reproduce one bug, isolate one flaky test, understand one strange user flow. Then you have to zoom all the way out, far enough to see where that problem sits in the whole system, how it connects to other problems, and whether it even matters next to everything else on the board. Then you zoom back in. That movement, in and out, is what separates someone who runs tests from someone who improves a system.

The view we start with

Most of us begin, and many of us stay, zoomed all the way in on one spot, manual testing and automation testing. Write the cases, run the builds, log the bugs, chase the fixes. It is real work and it matters, but it is a single corner of a much larger map. When that corner is all you can see, it quietly becomes the whole definition of the job, and everything else falls to someone else or to no one at all.

Working without the map

You can see the cost of the narrow view at planning time. Ask a lot of QA teams what their goals are for the quarter or the year, and they go looking for something to do so they have a goal to point at. A new tool here, more coverage there, a number to chase. The order is backwards. The goal should come first, from a clear read of where the system actually is, and only then do you zoom in on the specific part worth solving right now. Without the wider view, you stay busy and still drift.

The whole map

What pulled this into focus for me was running maturity assessments for clients, working with models like the TMMi. Laying QA out as a map of maturity, from the initial, ad-hoc stage through managed, defined, measured, and finally optimised, you see just how much there is. And it is not one dimension. Test types are only one branch. Alongside them sit your test operations and infrastructure, your observability, and your metrics, and every one of those grows and shifts as a team matures.

Seen that way, manual and automation testing is one or two labels, on one branch, at one early stage, of five. The part we usually argue about is a dot. The rest of the map, the part that makes a system genuinely better and able to sustain itself, only shows up once you are willing to zoom out and look at it.

So here is that whole map as something you can explore. Start zoomed in on the build, then zoom out through the levels, and tap anything you have not seen before.

Every layer sees something different

What makes this genuinely exciting, at least to me, is that each part of that map looks at quality from a different angle, and they feed off each other.

The test types alone are a world: manual, exploratory, functional, regression, performance, security, reliability, chaos engineering, mutation testing, and that is before you get clever about it. Metrics turn all of that into something you can actually see, the defect leakage, the cost of quality, the reliability growth that tells you whether anything is really improving. Observability comes at it from another direction entirely, tracing, real-user monitoring, synthetic checks, showing you how the system behaves in the wild rather than how it behaved in a test. And TestOps and infrastructure is the engine room underneath all of it, the pipelines, environments, and frameworks that let everything else run at all.

None of these stand alone. A metric only means something when observability shows you the behaviour behind it. Automation is only as good as the infrastructure it runs on. Pull back far enough and you stop seeing separate disciplines and start seeing one system, where understanding one part makes every other part make more sense.

You do not have to be an expert in all of it. I am not. But you do have to want to understand it, and that is the part that keeps me hooked. QA is not one skill, it is a dozen overlapping crafts, each with its own depth, each feeding the others. There is always another level to zoom into, and that is exactly what makes it worth doing.

Why the zoom matters

This is not about doing more for its own sake. A team that only ever zooms in fixes symptoms and never notices the pattern underneath. A team that only ever zooms out talks strategy and never ships a fix. The value is in the movement. Zoom in to solve the real, specific problem in front of you. Zoom out to understand what it connects to and whether it is even the right problem. Then zoom back in with that perspective, and you start catching the things you used to walk straight past.

QA was never just testing the build and chasing feedback. It is the discipline of seeing the whole system clearly, at every level, and knowing which level to stand on right now.