What If We Coded Without A Net?
The most spectacular part of any circus is when the trapeze artists defy death and the nets are pulled back. Ever fearless, they forge on through their act, leaps and twirls and flips. It's exciting because you don't want to think of what could happen. Safety nets are there for a reason. As spectators, we awe over the audacity of not having a fallback plan.
That's the role QA plays in most software development teams. We plan for code coverage and test metrics to ensure that most (not all) possibilities are accounted for. We are the safety net, the last bastion against defects in production. Yahoo has taken its place among the great escape artists and aerial tricksters, as it removes its safety net. There are no more QA teams at Yahoo.
Yahoo doing away with QA teams seems to fly in the face of conventional wisdom and decades of best practices for software development.
A wise decision? Testing in production is nothing new -- every dev team has done it to some degree, begrudgingly though. Subjecting users to untested code makes for an unpleasant experience for them in most cases, and the usual headache for coders hurrying to catch up on trouble tickets.
As we start to crunch the SDLC into ever smaller bits, as we turn from releases to continuous delivery pushing the limits of what is possible was inevitable. Do away with testing? Sure. We're all but one step away from getting rid of local development environments and having customers watch as code is written live, streaming over an internet IDE.
After reviewing most of what Yahoo claims, I began to understand that they're not really getting rid of the QA mentality or role. They have "shifted left" those testing tasks to now fall on the shoulders of the developers. Turning programmers into SDETs is not a simple overnight process. Programming and testing are two completely separate mindsets with distinct goals in mind. While to some they may seem to overlap, it's important to understand what the objectives are for each team member.
Coders code. Testers test. It's not quite that simplistic, but I go into a testing project thinking of ways to break an application. Add a SQL injection here, or click two buttons simultaneously there. How about I randomly throw in a 100-digit alphanumeric username? I like to think of my duties as behaving like a customer who doesn't bother to read manuals or read help files. Devil be damned, I'm going to do it "my" way and see what happens. I don't think you get that when you wear both the programmer's hat and the tester's hat.
Development without a safety net might seem like a progressive idea, but don't forget that no matter what precautions are or are not in place, it's still a circus. And anything can happen.
