No More QA: Yahoo's Tech Leaders Say Engineers Are Better Off Coding With No Net (ieee.org)

Tekla Perry writes: A year ago Yahoo eliminated its test and quality assurance team, as part of project Warp Drive, its move to continuous delivery of code. The shift wasn't easy, Yahoo tech execs say, and required some "tough parenting." But the result has been fewer errors because "when you have humans everywhere, checking this, checking that, they add so much human error into the chain that, when you take them out, even if you fail sometimes, overall you are doing better." And the pain wasn't as great as expected. Yahoo's chief architect and SVP of science and technology discuss the transition.

Comments

Sounds like an MBA plan!

[Dunbal]

We were tired of being constantly bogged down by all these mistakes and bugs, so we got rid of the people who kept telling us about all the mistakes and bugs. Now our code is 100% mistake and bug free! Next step, get rid of our expensive experienced coders and replace them with cheaper outsourced coders with "equivalent" experience. We'll save so much money what could possibly go wrong? And the third and final phase of our plan is that in order to motivate our coders we will be paying a bonus that scales with the amount of code written. The more code you write, the better the bonus!

Don't you just love management?

Re:Sounds like an MBA plan!

[Junta]

The argument is actually pretty bad. By all means add more automated testing and hopefully make the QA process smoother, but skipping it entirely (they fired the QA team) is a recipe for disaster, and the only thing they have to measure the effectiveness of this is the number of issues in their issue tracker, which was *fed* by the QA team. It's like a company firing all their warranty people and bragging about how their warranty claims have gone to zero. The filed issues may be lower, but that does not speak to the final product.

Testers don't always follow proper testing procedure

This is a double edged sword in my experience. The testers are using the software much like a human would, and they do unexpected human things like the end user would be doing. This particularly helps identify usability issues, which isn't really an automation sort of thing. It's also a lot of fuzzy stuff that is usually not specifically laid out in the spec.

robustness towards matching the spec

Sometimes single minded march toward matching the spec is a bad idea, because the spec is bad and needs to be revisited. Sometimes this plays out in development, and sometimes this plays out in QA when humans clearly have a harder time with the interfaces than expected. Also generally speaking for me a spec is pretty high level, open to interpretation, and refined throughout the process as the details of the implementation get fleshed out.

Re: Sounds like an MBA plan!

[rgmoore]

It was up to me to make sure my own code was quality enough before releasing it, and that aspect terrified me enough that I did learn to write quality code (which basically means you are testing your own code thoroughly, doing your own QA).

The problem with testing your own code is that you're likely to miss entire classes of bugs. You can be very effective at catching the kinds of bugs you can think of, but those are always the easiest bugs to catch in the first place. The tests you write for yourself will never do a good job of catching errors in your assumptions about what the code should do, what kinds of inputs it needs to handle, etc. Catching those kinds of conceptual bugs really requires adversarial testing from somebody who isn't starting from the same set of assumptions.

Re: Sounds like an MBA plan!

[phantomfive]

Yeap. That's where pushing to live production is going to be your brutal tutor.....if you have cognitive biases that are hiding bugs from your psyche, then the system will show you to them (most likely in the most inconvenient time), and you will learn. It's harsh.

You can get the same experience (but with less harshness) by giving yourself the goal to never let a bug get past you to QA. Then QA will be a kinder tutor that helps you learn.

Re: Sounds like an MBA plan!

[phantomfive]

Another thing I've learned is that the stereotypical animosity between dev and QA is counterproductive.

Yes. QA is absolutely on your side!! Every time they find a bug for me, I thank them profusely, because better them than a customer.

Re: Sounds like an MBA plan!

[phantomfive]

Do you think that users' data security is the proper object of harsh lessons for coders?

If you are depending on QA to make sure user data is secure, you're going to fail. That's not what QA does, and hacking is rarely in their skillset.

When companies start caring about security, they usually start a separate team "Red Team" or something whose entire job is to try to hack and find security holes in the project. (I would argue this is not sufficient, because companies who have done this still fail. If you want secure software, it has to start from the beginning. You need to teach your programmers how to write good code, and security has to be a priority on every line of code that is written. Security can't be tacked on as an afterthought).

Do they know what QA is?

[Razed By TV]

If your QA people are adding to the problems, you are probably doing it wrong.