It's the End of QA as We Know It ...

Soundtrack

As software development has moved to Agile and now to DevOps and continuous deployment there are those questioning the need to have a QA or testing department. From the infamous GTAC 2011 Keynote Test is Dead to Eli Lopian's post The Day the QA Department Died to Prezi's How did dissolving the QA team enable the DevOps culture at Prezi there has been some discussion about how QA fits in with Agile and DevOps. Mirco Hering in a recent post on Not A Factory Anymore called The Testing Centre of Excellence is dead, Long Live the Centre of Quality Engineering argues that due to the rise of the importance of speed to market and the cost of the temporal delay between finding defects and the actually creation of the code means that a separate team that comes in tests the code doesn't really work in this scenario.

Cheap, Fast and Good Enough

Another factor, especially true for cloud/SaaS offerings with a mature continuous deployment pipeline, is the plummeting cost of failure. Back in the days when software was shipped on physical media a defect making it into GA could be extremely costly. New versions of a CD ROM might need to be burned. Box art and manuals printed. Translations updated. All these materials shipped and assembled into product and shipped to customers. Existing stock shipped back and destroyed. 

All this cost real money so it was in the interest of the business to be cautious about defects escaping into production. Even moving to digital delivery still had associated costs. The updated release needed to be gathered, staged and pushed to the delivery channel like an e-commerce site or content delivery network. The additional costs in this case are mostly labor (rather than physical goods) but time your release engineering team spends on pushing errata is time people aren't spending creating new value.

Today's SaaS offerings can roll back in minutes. Why pay to try to detect all possible defects when you can push an experiment to production and canary or A/B test it fast and roll it back faster if it fails?

We Wanted This

In this new environment the key is to move to a model of "continuous quality". For years QA folk have been advocating moving quality practices "to the left" in the software development process. We wished developers would write unit tests, we advocated for pervasive test automation and static analysis frameworks. Code reviews. We dreamed about continuous integration systems. We crossed the aisle and worked closely with our developers to test and debug hairy problems. We cavorted with our brothers and sisters in support over customer reported issues. We wanted everyone in software delivery to care about quality. Now more people do.

Years ago a QA colleague of mine would often joke "I'm just trying to automate my way out of a job." With the rise of continuous deployment pipelines it is now a possibility. File under "Be careful what you wish for ..." So what will be come of us in this new reality? Personally I'm excited and hopeful because I believe that there are numerous places where a "tester's mindset" can be of value to business in this brave new world. I'll share my thoughts on that in my next post.

It's the end of QA as we know it ... and I feel fine.