<story><title>Yahoo’s Engineers Move to Coding Without a QA Team</title><url>http://spectrum.ieee.org/view-from-the-valley/computing/software/yahoos-engineers-move-to-coding-without-a-net</url></story><parent_chain><item><author>DougWebb</author><text>That&amp;#x27;s a management problem, not a problem with having a QA team. The top-level QA manager and the top-level Dev manager should both report to the CTO, and the Dev manager should be judged by how many issues the QA team finds. To keep things fair, the QA manager should &lt;i&gt;not&lt;/i&gt; be rewarded nor penalized based on the number of issues found pre-release, and everyone should be rewarded or penalized based on the number of issues found post-release.&lt;p&gt;This keeps the devs incentivized to make sure everything works before the code goes to QA, and it keeps everyone incentivized to eliminate as many bugs as possible before release.</text></item><item><author>jboy55</author><text>I&amp;#x27;m in full agreement.&lt;p&gt;In practise, a manual QA team encourages Devs to throw shit over the wall and expect someone else to do some basic sanity checks they should have already done. By the time those are done, what the QA team theoretically could find gets shipped.&lt;p&gt;Then, when its discovered in Prod, the QA team will get in the way of a speedy fix.</text></item><item><author>arielweisberg</author><text>Moving from an environment with a 10:1 dev:qa to 2:1 showed me what happens when dev is not responsible for shipping working software.&lt;p&gt;No thanks. It&amp;#x27;s a bunch of deflection and diffusion of responsibility coupled with high latency flakey interactions between different teams. Everything that can slip through the cracks does slip through the cracks.&lt;p&gt;I&amp;#x27;m sure QA can be done well, but I am convinced that giving your devs a pass to not finish their work is a dead end in several dimensions.</text></item><item><author>ef4</author><text>Surprised to see the negativity here. I have worked in environments with traditional manual QA, and environments where all development is test-driven and nobody is allowed to merge a feature that lacks automated test coverage.&lt;p&gt;Both the productivity and the quality were higher in the places with fully automated testing. Which is not shocking at all: does anybody really think a human can run through 800 test cases better than a computer can?&lt;p&gt;It&amp;#x27;s not a magic way to save money -- the developers obviously end up spending time writing tests. But the long-term value of those tests is cumulative, whereas the effort spent on manual testing is spent anew every release.&lt;p&gt;Manual review is still good for noticing things that &amp;quot;feel wrong&amp;quot; or for helping think up new corner cases. But those bleed into product owner &amp;amp; design concerns, and aren&amp;#x27;t really a separate function.</text></item></parent_chain><comment><author>vkou</author><text>What will happen is that devs will ask their QA counterparts to report issues through an undocumented side-channel.&lt;p&gt;If you give an engineer a career incentive to optimize something, you&amp;#x27;d be surprised how seriously some will take it.</text></comment>
<story><title>Yahoo’s Engineers Move to Coding Without a QA Team</title><url>http://spectrum.ieee.org/view-from-the-valley/computing/software/yahoos-engineers-move-to-coding-without-a-net</url></story><parent_chain><item><author>DougWebb</author><text>That&amp;#x27;s a management problem, not a problem with having a QA team. The top-level QA manager and the top-level Dev manager should both report to the CTO, and the Dev manager should be judged by how many issues the QA team finds. To keep things fair, the QA manager should &lt;i&gt;not&lt;/i&gt; be rewarded nor penalized based on the number of issues found pre-release, and everyone should be rewarded or penalized based on the number of issues found post-release.&lt;p&gt;This keeps the devs incentivized to make sure everything works before the code goes to QA, and it keeps everyone incentivized to eliminate as many bugs as possible before release.</text></item><item><author>jboy55</author><text>I&amp;#x27;m in full agreement.&lt;p&gt;In practise, a manual QA team encourages Devs to throw shit over the wall and expect someone else to do some basic sanity checks they should have already done. By the time those are done, what the QA team theoretically could find gets shipped.&lt;p&gt;Then, when its discovered in Prod, the QA team will get in the way of a speedy fix.</text></item><item><author>arielweisberg</author><text>Moving from an environment with a 10:1 dev:qa to 2:1 showed me what happens when dev is not responsible for shipping working software.&lt;p&gt;No thanks. It&amp;#x27;s a bunch of deflection and diffusion of responsibility coupled with high latency flakey interactions between different teams. Everything that can slip through the cracks does slip through the cracks.&lt;p&gt;I&amp;#x27;m sure QA can be done well, but I am convinced that giving your devs a pass to not finish their work is a dead end in several dimensions.</text></item><item><author>ef4</author><text>Surprised to see the negativity here. I have worked in environments with traditional manual QA, and environments where all development is test-driven and nobody is allowed to merge a feature that lacks automated test coverage.&lt;p&gt;Both the productivity and the quality were higher in the places with fully automated testing. Which is not shocking at all: does anybody really think a human can run through 800 test cases better than a computer can?&lt;p&gt;It&amp;#x27;s not a magic way to save money -- the developers obviously end up spending time writing tests. But the long-term value of those tests is cumulative, whereas the effort spent on manual testing is spent anew every release.&lt;p&gt;Manual review is still good for noticing things that &amp;quot;feel wrong&amp;quot; or for helping think up new corner cases. But those bleed into product owner &amp;amp; design concerns, and aren&amp;#x27;t really a separate function.</text></item></parent_chain><comment><author>fein</author><text>Have you ever worked for a fortune 100 company? The dev manager has probably never met the CTO. Im in this right now with my currrent job. I still keep my builds and test them longer than i should. Less broken shit gets through, but i regularly delay my qa ba&amp;#x27;s because of it.</text></comment>