An article from last December got me thinking hard about quality assurance – why all of the QA Hate?
So, Yahoo got rid of their Quality Assurance team going to what they call “Warp Drive,” a system of continuous improvement. Or rather, a “shift from batch releases of code to a system of continuous delivery.” Software engineers at Yahoo are no longer permitted to hand off their completed code to another team for cross checking. Instead, the code goes live as-is; [and guess what?] if it has problems, it will fail and shut down systems, directly affecting Yahoo’s customers.
So why does this matter?
Programs and networks go live as is, even if there are problems, which directly affect customers. Even though this system makes developers think different, why all of the hate?
Several things stand out to me about this article and the commentary around the internet about it:
1) QA should have/could have been a leader in the move to continuous integration. Testing and “continuous improvement” are not mutually exclusive.
2) Even if there was a lot of manual testing happening, that doesn’t mean that QA or testing should have gone away, it just means that there was a need for more automation and repeatable regression testing.
3) Saying that developers should be so good that they only push code that won’t break production sounds “macho.” The reality is that this kind of expectation yields more overworked developers.
4) Having developers do both testing and development leads to context switching ala the kind Tom DeMarco warned the industry about decades ago in his book Peopleware. Plus, while there has always been an industry myth that “good” developers can do anything, the practical reality is that testing and QA are different career disciplines within production software development. Simply stated, there are different skills sets and expertise at play.
5) Restructuring has been a trend over the past decade that has been driven by the need to move to more agile practices. The truth is however, it comes at the expense of quality assurance. In most places, cost-cutting is at the forefront instead of quality-driven process improvements.
Bottom Line: before finding supposed efficiencies for work progress and product development, substantial thought should be given to the affects the so-called efficiencies have on developers and most importantly, customers in the long run.