Live data from Hacker News

Yahoo’s Engineers Move to Coding Without a QA Team

spectrum.ieee.org

51–60 of 188 posts

Re: Yahoo’s Engineers Move to Coding Without a QA Team

#52
post #46
post #19

Earlier quoted context omitted.

They might as well take out the trash and clean the floors on their way out. Vertically integrated!

Definitely. Writing software : writing software to test software as writing software : cleaning the floors.

Clearly you've forgotten that doing anything one doesn't want to do, even if it's still software and absolutely part of their job, is "being forced to do it for no extra pay."

Re: Yahoo’s Engineers Move to Coding Without a QA Team

#54
post #20

This is actually a story about the triumph of continuous integration and staged rollout. By shipping code constantly, but slowly rolling it out to users - bugs can be detected very quickly by the users themselves, instead of employing large QA teams. Keeping a central code repository, automating builds, frequent commits and automatic tests for code are taking away a lot of load for QA teams.

...triumph of continuous integration and staged rollout.

This makes sense to me. The fact that this wouldn't have worked at the old-style "enterprisey" places we used to work at doesn't say much in general. (It may not work at Y! either, but it seems possible...)

Re: Yahoo’s Engineers Move to Coding Without a QA Team

#55
TL;DR: QA is changing - just like everything else.

The article makes the assumption that QA == manual QA which as a quality professional is false. Quality is about measuring risk across the development process. Immature team need manual QA while mature (in a process/quality sense) teams need much less (or none).

Quality professionals who want a sustained career needs to learn development processes, opts, documentation & monitoring. We make teams better.

Re: Yahoo’s Engineers Move to Coding Without a QA Team

#56
When measuring the effectiveness via reduction of issues, how do you account the natural stability introduced by reducing the updates/week each developer ships? When devs are tasked with code reviews and/or QA, this is time that could have been spent on their own features. In other words, if the product is stable today, and everyone's on vacation (no new updates), the product will generally remain stable save for unforeseen usage patterns.

Re: Yahoo’s Engineers Move to Coding Without a QA Team

#57
Updated TL;DR: QA is changing - just like everything else.

The article makes the assumption that QA == manual QA which as a quality professional is false. Quality is about measuring risk across the development process. Immature team need manual QA while mature (in a process/quality sense) teams need much less (or none).

Quality professionals who want a sustained career needs to learn development processes, opts, documentation & monitoring. We make teams better.

Re: Yahoo’s Engineers Move to Coding Without a QA Team

#58
post #19

Earlier quoted context omitted.

I mean, they have a salary, so unless the engineers are required to stay extra hours to do the QA it makes no difference to them.

They might as well take out the trash and clean the floors on their way out. Vertically integrated!

I have worked in small companies before where there were no janitorial services, so we emptied our trash cans once a week, and took turns taking the larger bags to the dumpster outside. What's the big deal? And that's not a rhetorical question. I truthfully want to know why you think something like that is silly.

Re: Yahoo’s Engineers Move to Coding Without a QA Team

#59
post #4

TL;DR: They fired the QA team to save money. Then they made the engineers do the QA work for no extra pay.

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.

Re: Yahoo’s Engineers Move to Coding Without a QA Team

#60
post #48
post #29

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. 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 bett…

> Which is not shocking at all: does anybody really think a human can run through 800 test cases better than a computer can? I think this rather misses the point; it's the bug that doesn't have a test case where QA helps.

Exactly. And having the computer run through 800 checks means a skilled tester can do what they are good at - finding bugs.
Post reply on HN