| | November 20168CIOReviewShould We Get Rid of the Software QA Department?By Derek Yoo, CTO, FuzeIt was recently reported that Yahoo has gotten rid of their QA department. The number of comments this post attracted made me think of a CTO conference I recently attended, where the same question had come up. The conference audience was fairly split on the issue, with several CTOs pursuing a similar strategy to Yahoo, and other CTOs staying with a traditional centralized QA department. The question definitely struck a nerve, and people in both camps were animated in defending their practices. Those of you coming from older, more established companies are probably thinking, "Get rid of the QA department? Are you nuts? Who is going to be responsible for quality?"I have to admit--it does sound a little crazy to people like me who cut our teeth using a more traditional waterfall software development process. After all, as projects progress down the waterfall, we always needed QA as the last step to ensure reasonable quality levels for products. There was a fundamental check and balance built into the process where QA could push back on engineering if there were too many defects. This check was important, as the price for failing to deliver acceptable quality levels is high. Nothing undermines customer confidence and goodwill quicker than software with lots of bugs. So what is it really that Yahoo is saying when they talk about getting rid of QA?The argument that Yahoo and others are making is less about getting rid of QA, and more about moving where and who is responsible for software quality. In Yahoo's model, responsibility for quality is pushed back to engineering. By removing the formal QA step to the process before code gets shipped to market, you are in essence removing the "safety net" that engineers have enjoyed for a long time. With the safety net removed, the argument goes; engineers will be forced to behave differently. They will engineer quality and test automation into the software itself, resulting in higher, not lower quality in the software. Proponents of this camp go further to argue that the result is increased efficiency overall, with IN MY OPINION
< Page 7 | Page 9 >