4 ms·

How about the right version: They fired the QA team to force the devs to do a better job of designing for testability. When you have to write and plough throu

by dgacmu 11y ago

How about the right version: They fired the QA team to force the devs to do a better job of designing for testability. When you have to write and plough through your own tests, you integrate tests earlier, and you modularize your code better to support that testing. There's a lot in the early phases of engineering that the initial devs can do that QA cannot. QA is handed a black box; dev gets to change the box. It's a very similar big-picture realization as the move from "system administration" to SREs/devOps. Having a bunch of people throwing #@*( over the wall that other people then have to make work is a poor model for optimizing the big picture. This is a good move. It's Mayer taking another play from the Google playbook and trying to improve the process at Yahoo.

protomyth 11y ago
> They fired the QA team to force the devs to do a better job of designing for testability If that is actually true, then they should have fired the Devs and found ones who understand writing correct and testable code. That is a horrible way to treat people.
- dgacmu 11y ago
  I think we must be misunderstanding each other. Developers are human. (At least, I think we are.) We respond to the incentives and structure of the environment in which we're developing. A culture of "throw crap over the wall to QA" naturally creates an incentive for quickly writing up features, without balancing that with robustness, because finding the problems "is QA's fault". A culture of "the devs are responsible for the quality of their code" produces better code. The way to treat the devs well is to have the QA folks go off and create or bring in easy-to-use automated testing and CI frameworks, to make it easy for the devs to do the right thing. This is not a new observation - it's been happening over the last 10 years. see, for example, http://blogs.forrester.com/mike_gualtieri/11-02-17-want_better_quality_fire_your_qa_team http://blogs.forrester.com/mike_gualtieri/11-02-17-want_bett... or http://product.hubspot.com/blog/the-classic-qa-team-is-obsolete http://product.hubspot.com/blog/the-classic-qa-team-is-obsol... and, while it's from 2007, http://googletesting.blogspot.com/2007/03/difference-between-qa-qc-and-test.html http://googletesting.blogspot.com/2007/03/difference-between...
  - protomyth 11y ago
    > Developers are human So are Q&A people. They are the developer's teams members not their minions. > We respond to the incentives and structure of the environment in which we're developing. A culture of "throw crap over the wall to QA" naturally creates an incentive for quickly writing up features, without balancing that with robustness, because finding the problems "is QA's fault". A culture of "the devs are responsible for the quality of their code" produces better code. I'm wondering why the presence of a Q&A team would in any way change the professional responsibility of developers to create correct, testable code. If your developers have developed a culture of "throw crap over the wall to QA", then that's on the developers. > The way to treat the devs well is to have the QA folks go off and create or bring in easy-to-use automated testing and CI frameworks, to make it easy for the devs to do the right thing. That is not really the function of QA. Developers need to use proper testing tools on their own, but QA has its own function beyond just testing the code. They also test the assumptions and specification that the "business" ask the developer's to code. They look for bugs that go beyond what a certain set of test criteria instructs. It is also important to supply Q&A with tools to do fast, automated testing. Developer tools are not the function of Q&A. Q&A has a job to do, and its irresponsible for Developers use them as a substitute for their responsibilities. As an example from other industries, safety is not just the Safety Officer's problem. // I've been equal years developer and system admin working with good and bad Q&A people

by dgacmu 11y ago

protomyth 11y ago

> They fired the QA team to force the devs to do a better job of designing for testability If that is actually true, then they should have fired the Devs and found ones who understand writing correct and testable code. That is a horrible way to treat people.

dgacmu 11y ago
I think we must be misunderstanding each other. Developers are human. (At least, I think we are.) We respond to the incentives and structure of the environment in which we're developing. A culture of "throw crap over the wall to QA" naturally creates an incentive for quickly writing up features, without balancing that with robustness, because finding the problems "is QA's fault". A culture of "the devs are responsible for the quality of their code" produces better code. The way to treat the devs well is to have the QA folks go off and create or bring in easy-to-use automated testing and CI frameworks, to make it easy for the devs to do the right thing. This is not a new observation - it's been happening over the last 10 years. see, for example, http://blogs.forrester.com/mike_gualtieri/11-02-17-want_better_quality_fire_your_qa_team http://blogs.forrester.com/mike_gualtieri/11-02-17-want_bett... or http://product.hubspot.com/blog/the-classic-qa-team-is-obsolete http://product.hubspot.com/blog/the-classic-qa-team-is-obsol... and, while it's from 2007, http://googletesting.blogspot.com/2007/03/difference-between-qa-qc-and-test.html http://googletesting.blogspot.com/2007/03/difference-between...
- protomyth 11y ago
  > Developers are human So are Q&A people. They are the developer's teams members not their minions. > We respond to the incentives and structure of the environment in which we're developing. A culture of "throw crap over the wall to QA" naturally creates an incentive for quickly writing up features, without balancing that with robustness, because finding the problems "is QA's fault". A culture of "the devs are responsible for the quality of their code" produces better code. I'm wondering why the presence of a Q&A team would in any way change the professional responsibility of developers to create correct, testable code. If your developers have developed a culture of "throw crap over the wall to QA", then that's on the developers. > The way to treat the devs well is to have the QA folks go off and create or bring in easy-to-use automated testing and CI frameworks, to make it easy for the devs to do the right thing. That is not really the function of QA. Developers need to use proper testing tools on their own, but QA has its own function beyond just testing the code. They also test the assumptions and specification that the "business" ask the developer's to code. They look for bugs that go beyond what a certain set of test criteria instructs. It is also important to supply Q&A with tools to do fast, automated testing. Developer tools are not the function of Q&A. Q&A has a job to do, and its irresponsible for Developers use them as a substitute for their responsibilities. As an example from other industries, safety is not just the Safety Officer's problem. // I've been equal years developer and system admin working with good and bad Q&A people