Quality Assurance

Developers used to check their own code and deploy it. On a small team that works well enough: you know what you touched, and you fix what breaks within the hour.

It stopped working as headcount grew and features began depending on each other. Whoever built something tests the path they had in mind. Cancelling an upload halfway through, opening a link from an account without permission, editing the same document in two browser windows — none of those are in the builder's head. The larger problem is things breaking that nobody touched. Fixing sharing and stopping comment notifications is that shape, and it was never on the builder's list to check because they had no reason to suspect it.

Quality assurance (QA) separates that checking from the building and stands it up as its own activity: different eyes, a written list, and a verdict on whether this can go out. None of those three parts works without the other two. What defines it is that it isn't another round of tests but the procedure a release decision rests on, which is why it has a verdict at the end rather than a score.

Build the list of what to check, walk it, file what you find, and re-check what got fixed.

1. Write the list. The normal path and the failure paths of whatever changed, plus the other features the changed code reaches into. The second half is the part that takes judgment, and it is where an experienced reviewer earns their keep. Where the requirement document carries acceptance criteria, the conditions for calling a story finished, those sentences become the first entries.
2. Split what a machine checks from what a person checks. Unit tests, which isolate one function, and end-to-end tests, which drive a browser through a whole flow, run automatically. People look at what machines judge poorly: whether the wording suits the situation, whether an error message says what to do next, whether something on screen simply looks wrong to a person seeing it for the first time.
3. Check what nobody touched. Regression testing, verifying that what used to work still works, sits here. The list grows over time, so whatever breaks most often gets automated first. Past about 200 manual items a release takes two days, and from there people start shrinking the list instead of shrinking the risk it was written to cover.
4. File what you find. Reproduction steps, expected behavior, actual behavior, and a severity — the size of the impact on the service.
5. Re-check the fixes and give a verdict. Weigh the severity of what remains and decide to ship or hold, with the decision written down rather than assumed. Right after a deploy, a smoke test covering only the essentials decides within minutes whether to roll back, and the shortness of that check is the point of it.

Where there's a dedicated person, they build the list and lead the verdict, and the list becomes an asset the team keeps rather than something rewritten each time. Where there isn't, a developer other than the author takes that role. Either way the principle is the same: the person who built something is not the final judge of whether it is finished.

Three more people come in. The designer who drew the screens checks the implementation against the design. The product manager who wrote the requirement checks that everything in scope actually arrived, and that nothing outside it arrived along with it. Support asks for the areas that generated the most tickets last quarter to be added to the list — they know where users actually got stuck, so list quality rises through that request more than through any internal review.

Timing attaches to the release cadence. Pagedeck deploys twice a week and spends the afternoon before each deploy on this. Two more moments matter. One is mid-build: receiving the list after the work is finished makes fixes expensive, so the list gets shared before development starts and the builder walks those paths first, which removes most of the easy findings before anyone else looks. The other is after an incident, when the missed path joins the list so the same class of failure doesn't ship again.

"Three defects left in this release, all low severity. It can ship."

Stating the basis for the verdict in terms of severity rather than defect count.

"Send me the check list for this feature before development starts."

A request to know the paths in advance and build for them rather than around them.

"Sharing is fixed but notifications stopped. Regression caught it."

Reporting something that broke without anyone touching it directly.

At Pagedeck a release that changed document sharing permissions was stopped by this procedure. What Theo built worked on the normal path, and one failure path on the list turned out to let an account without permission open the link.

Whoever found it filed it at high severity, and the release slipped by a day as a result. That day can look wasteful, and had the same defect shipped, every link already created would have needed auditing. The difference between those two outcomes is where this activity earns its place, and it is almost never visible when the procedure is working.

The most common mistake is using it interchangeably with testing. Most of what happens here is testing, so the confusion is natural. But a test is the instrument that checks whether code behaves as intended, and quality assurance is the activity that decides which instruments to use on what, and turns the results into a release verdict. However many tests exist, without a decision about what is deliberately not being checked, something different slips through every release and nobody can say why.

Believing this activity produces quality is the other one. Assurance is in the name, so it looks like where quality gets decided. But all that can happen here is finding what's wrong inside something already built. A bad design or a vaguely written requirement cannot be fixed at this stage — only found and sent back, at the point in the schedule where sending anything back is most expensive. So strengthening only this activity increases the number of things that turn around right before a release. Moving the list earlier in development is the practical answer to that, which is why step one keeps migrating toward the start of the work.