Slashdot Mirror
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.
Did you get through TFS? The claim is that overall errors have been reduced but not eliminated.
He could be lying, but if that's the counterclaim, then show some evidence for it.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Where are my mod points? TDD is not the elimination of test and quality assurance, it's the procedualization / automation of it - along with driving it further forward in the product development cycle.
To do TDD, you need less (or no) QA people at the end, and more QA work in early development. If you choose to do this by firing the QA department, you probably are getting your product to market slower. If, instead, you transition the frustrated programmers who have been stuck in QA since graduating into design, implementation, and maintenance of automated tests for the project, you're probably winning big.
While 100% was hyperbole, I think the point stands: if you remove QA then the number of *known* issues is going to go down. Whether your number of *actual* issues go down it's another matter.
I view this as the nightmare scenario, management hears words like automated testing as part of CI and then assumes automation has taken care of everything and they don't need the QA people. When the QA people's input into the issue tracker goes away, the numbers of issues in the graphs go down. Management gives themselves a pat on the back as a problematic metric has improved, without too much thought as to why.
XML is like violence. If it doesn't solve the problem, use more.
I very much doubt that they were smart enough to begin the transition to TDD before they eliminated their QA department.
I worked quality assurance at a very-much test level without really delving into code. Programmers can be effin' stupid at times. I was testing daemons for communications protocols. I took four approaches. Verify that it does what it's supposed to do per RFC. Investigate the behavior when confronted with stale RFCs. Investigate the behavior when it's confronted with non-RFC input that is commonly available in end-user applications (ie, non-malicious incorrect use), and investigate the behavior when malicious intent is used. I can tell you that programmers working on these protocols wrote them to current-RFC only and that they were quite upset when testing obsolete commands from previous versions of RFC broke things, or when the third-party applications sent stuff to the daemons and broke them. I would have been understanding if the software had failed gracefully, with a warning or a 500 code or the like, but when sending obsolete POP3 commands to a POP3 daemon causes it to crash hard, or when encoding an attachment with Mac BinHex instead of MIME makes it crash, both of which were user-selectable options in then-popular Eudora (the client that the company itself used) then there's a big problem. I didn't even have to get to the level of malicious testing things were so bad.
The point of a good quality assurance tester is to concoct out-of-the-box but plausible tests to try to break it. It has a lot in common with Security; it requires a degree of white-hat maliciousness and a need to use other kinds of experiences from other disciplines to devise the scenarios to use. It also requires the tester to have good communications skills as they may have to work to convince the development team that what they've found actually is a problem and being too antisocial or too introverted might not get problems corrected even if they are important and are discovered.
Yahoo is doing a hell of a job in convincing me that they're really not worth paying attention to anymore. They are taking a position that is risky and is arguably excessively risky relative to the size and position of the company.
Do not look into laser with remaining eye.
He could be lying, but if that's the counterclaim, then show some evidence for it.
I hold in my hand a bag containing a small, living, pink unicorn.
What do you say? I'm lying? Well, if that's the counterclaim, then show some evidence for it.
What do you say? You can't look in the bag? Well, my point exactly.
The claim is that overall errors have been reduced but not eliminated.
But with zero testing, how would they know?