Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yahoo’s Engineers Move to Coding Without a QA Team

spectrum.ieee.org

Post reply on HN
Print view View original

41–50 of 188 posts

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

#41

Post by grillvogel »

dkopi wrote: 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.

obvious bugs in basic functionality can be detected by automation

the nastiest bugs will be found by either a manual tester or your customer.

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

#42

Post by jsprogrammer »

ef4 wrote: 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…

QA is essential. How else do you know that you have built what you set out to built? Traditional manual QA is highly effective, so much so, that you can get huge gains by automating it. QA occurs at many levels and it makes sense to have a dedicated QA team for each level. Generally, the QA team for a level should be the exact people who requested and/or approved the specific feature subject to QA, as they are in the best position to confirm or deny that the feature meets the specification, as they created and/or approved it.

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

#43

Post by CodeSheikh »

Dev writing automation tests for their code is kinda pointless. It would be better to have another dev or a different team such as automation engineers writing regression automation tests. Automating regression tests is definitely better than manual QA-ing the same 1000 tests over and over again. There has to be a good balance. Have extensive coverage of automated regression tests and let manual QA test new features. This will at least increase the frequency of release cycles. Getting rid of an entire QA dept is somewhat equivalent to shooting yourself in the foot.

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

#44

Post by pc86 »

ef4 wrote: 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…

The arguments here such as "oh they just make the devs do it and don't pay them anymore" are ridiculous. Nobody's working 80 hour weeks doing two full-time jobs at once.

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

#45

Post by pc86 »

arielweisberg wrote: post #37
ef4 wrote: 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…

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. No thanks. It'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. I'm sure QA can be done well, but I am convinced that giving your devs…

The best way I've seen it done is when another developer, on the same team, who is responsible for the same product, reviews your code. Not someone who writes tests for a living, someone who does the exact same job as you on the same product.

Any time I've experienced something different it's been exactly as you described.

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

#46

Post by ftio »

jonknee wrote: post #19
austenallred wrote: post #11

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!

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

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

#47

Post by miles_matthias »

Quality assurance is important whether you do that via humans or code, but the thing that always bothered me about Q&A was that the ones I worked with were mindless people simply looking at the feature request and the functionality on the page and comparing the two without any thought towards the actual product, business, or user.

And in that system, the developer is completely removed from the product and is just another factory worker. The closer engineers can be to users (with design to translate obviously) the better for everyone.

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

#48

Post by duaneb »

ef4 wrote: 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.

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

#49

Post by pc86 »

jsprogrammer wrote: post #42
ef4 wrote: 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…

QA is essential. How else do you know that you have built what you set out to built? Traditional manual QA is highly effective, so much so, that you can get huge gains by automating it. QA occurs at many levels and it makes sense to have a dedicated QA team for each level. Generally, the QA team for a level should be the exact people who requested and/or approved the specific feature subject to QA, as they are in the…

But you're talking about QA as a general process, not QA as is meant in the article:

> Software engineers at Yahoo are no longer permitted to hand off their completed code to another team for cross checking.

Dev Team A was giving a batch of code to Dev Team B to review.

I agree that the business user/product owner/whatever should be reviewing everything in test prior to approval and in production after but I'm not sure that's the article means by QA.

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

#50

Post by sanderjd »

CodeSheikh wrote: post #43

Dev writing automation tests for their code is kinda pointless. It would be better to have another dev or a different team such as automation engineers writing regression automation tests. Automating regression tests is definitely better than manual QA-ing the same 1000 tests over and over again. There has to be a good balance. Have extensive coverage of automated regression tests and let manual QA test new features.…

This is basically my experience. I think the ideal situation is having development and QA cultures that both prioritize quality and automation. Development cultures sometimes fail to prioritize quality ("not our problem"), and QA teams sometimes fail to prioritize automation ("not how we do things"), but those are problems with those specific cultures, not with the entire concepts of development and QA.
Post reply on HN