A continuation my Lean and Agile, in Reverse series
We’ve now covered most of what I have to say about Production and how it benefits from fast iteration. Next I’d normally talk about Staging, except that Staging servers can be expensive, and you’re more likely to own Staging servers if you believe in Continuous Delivery, which pretty much presupposes you believe in Agile. Which means I don’t need to sell you on any of this because you’ve already bought in.
Since Staging is the last phase of the QA process, we’ll talk about QA instead.
A Well Oiled QA Machine
QA knows what to test because the Dev Team knows what they’re working on. In fact because the cycle is so short, they can write it all down for the QA Manager. Since they know what they’re working on, they know what they’ve touched recently, which means they have useful opinions on what builds are worth testing, and what other functionality they might have hypothetically broken without meaning to.
Since the Developers have already run their own tests, QA almost never gets Dead On Arrival builds. The building and packaging has happened often enough that at least some of the developers are pretty comfortable with the process, and it only breaks when there’s been a recent process change, if at all. Since everybody knows the drill with build, package and (re-)deploy, the QA team is almost always testing the right build, so few false positives occur. And no DOA builds means less downtime for the QA team.
With a roadmap in hand, on the back of a suite of automated tests, and on the assurances and honor of a Dev Team that’s actually trustworthy, the QA Manager can allocate most of the available resources to testing the riskiest and most obvious things immediately, and assigns only a handful of resources to regression testing. Since the cost of regression testing grows very slowly between releases, the project can keep pumping out Quality builds for an extremely long time.
A short test cycle gets timely feedback into the hands of the Developers. The Developers get an opportunity to fix bugs before they’ve layered very much code onto a bad foundation, improving code quality and reducing turnaround time down the road (less Tech Debt). And because the focus is on recently changed code, the Developers have a reasonable expectation that new bug reports are related to the work at hand. This makes them more receptive of being preempted by a Late Breaking Bug Report, and reduces the calendar hours or days between first report and the fix. And since any bug found in testing has to be re-tested, the short testing cycle pays off twice.
With all this maturity in place, the QA Manager has a pretty good idea of whether the build is fit for Release. In fact the Development Team may actually abdicate responsibility for signing off on releases entirely to the QA team, since they have other things to worry about.