Sunday, December 18, 2011

Do We Really Need A QA Phase Anymore?

Over the last year, as I learned more about how Google, Facebook and Flickr deploy software, I noticed little to no mention of QA. In fact often the developers themselves were pushing their commits live. Facebook does have a roll out gatekeeper, but from what I understand he's reviewing the commit and focusing on how damaging it could be in the case the developer made a mistake.

What's going on here.....

Why Does The QA Phase Exist At All

QA is a bit of a relic of the waterfall days - when software development was modeled after existing manufacturing methods. It's also easier for management to understand and to qualify it. They may have little to no idea what happens during software development, and more specifically development techniques that ensure higher quality in the first place (e.g. TDD), but they can understand that there is a process whereby the product is tested thoroughly in a very organized and documented fashion.

It's also plays well to the blame game. If a bug gets into a release, then it's the QA's fault because they didn't find it. In this way, QA becomes a safety net for both developers  (who may think they can get away with pushing out 'good enough' code ) and for managers who fail at providing a collaborative environment for their teams.
Let's Be Honest

How many organizations consider their QA as important as development, operations, sales.... not many I wager. In fact, I would argue that organizations claim that QA is one of those unquestionable 'you gotta have' steps. If that was the case, why is QA treated as optional when a deadline looms? When stress levels are high, this is when you start seeing what a organization considers as 'non-essential'. QA always falls into the 'non-essential'.

A big part of the problem is that high quality is assumed in a product. This is problematic because quality isn't something marketing can sell and it's something stakeholders have no interest in discussing. The fun stuff is in features and design - that's where the business value is. To many, QA has no business value.

While this certainly plays a part in the diminishment of the QA phase, this isn't the only reason....
How It's Done: QA Is Part Of the Team

Perhaps the biggest reason for the QA phase sunset has to do with the rise of SaaS, lean startup techniques and Agile development & delivery models. Now that we're developing and deploying in shorter cycles, a QA phase doesn't quite have a place. When developers are pushing commits straight to clients, even if a QA process was implemented, where would it fit?

To fit, QA now needs to be part of the same collaborative, rapid feedback environment that developers and management are now using. The QA gate needs to be torn down and the testing phase needs to be eliminated.

QA is done all the time, everyday, shoulder to shoulder with developers and management. If you practice SCRUM/Kanban stand ups, then QA is there too. When your team has kickoff, QA is there providing input to stories. When engineers check in features to version control, QA knows about it and can immediately write tests or perform any exploratory testing. If test cases need to be written, it's done with management & development.

This will seem like a lot of time collaborating and not much time working, but it's not. Remember that you should already be practicing continuous integration/testing/deployment/delivery. With QA involved in every step of the process, your feedback loops get smaller and everyone is aware of the risks.

QA now is shifting from an individual who unquestionably carries out a list of test cases, to a proactive consultant for the team.  This is something I've been working with my team on. I make sure QA is given an opportunity to provide feedback throughout the development process - from feature presentation,  feature poker, stand ups and of course, the risks of finial deployment of these features. This way when a member of the team delivers an update to the client, they are cognizant of any risks.

Perhaps one day we regard the idea of a QA phase with the same hindsight bias that we do with waterfall development.