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

81–90 of 188 posts

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

#81

Post by protomyth »

dgacmu wrote: post #59
Apreche wrote: 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…

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

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

#82

Post by jonknee »

pc86 wrote: post #58
jonknee wrote: post #19

Earlier quoted context omitted.

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.

Because Yahoo isn't a small company? They have been losing a lot of engineers and it must be hell to recruit people to join Yahoo, negative press like this is only going to make it worse.

As for why I think having Yahoo engineers take over janitorial duties is silly... If you're paying Silicon Valley engineering wages to someone (which they are, no one is going to Yahoo for stock options!) you should make sure they are working on engineering level tasks. It would be a giant waste of resources to have people do tasks they are overqualified for.

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

#83

Post by solomone »

vox_mollis wrote: post #28
mixmastamyk wrote: post #7

Great. I worked for a company that didn't invest in QA, it was consistently a !@#$% mess. When you do this, the need simply shifts to the customer. I wouldn't install our software until the 4th or 5th hotfix patch was available. Certainly, I'm an advocate of a more responsible dev team sharing the quality tasks and continuous integration too. But no QA at all? Hahah... maybe if you're a web portal that no one depends…

I worked for a company that didn't invest in QA Where are these magical places that do invest in QA? In nearly 20 years of professional development, I've never seen an organization in which the criteria for shipping was anything other than "works for me". I have never seen an organization in which there was either budget or managerial patience for proper QA, let alone anything other than VERY basic acceptance testing…

When I worked at Microsoft many years ago they had an large QA team with equal footing to Development and Product in determining what shipped and when. This was the same for every development team I was a part of there for over 9 years. It wasn't perfect, and the ship cycles were slow, but the quality bar was set higher than what I've seen outside of Microsoft.

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

#84

Post by serge2k »

pc86 wrote: post #44
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.

I still firmly believe this is a large part of the reason for having devs carry pagers.

Maybe in better companies than I worked it that isn't the case, but devs shouldn't be your 24/7 support staff.

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

#85

Post by rocky1138 »

philk10 wrote: post #25
slothguy72 wrote: post #12

They removed only MANUAL QA testing. There is a big difference between removing the QA team entirely and automating QA work.

and of course all manual testing can be automated... good luck with that.

That's what users are for!

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

#86

Post by transitorykris »

Removing dedicated QA (whether they do manual testing like in the article or write automated tests) and forcing the developers to take this on themselves is okay. Alternatively, I've had a lot of success with having development teams take operational responsibility for their code. They are not only naturally incentivized to take on automating QA, they also move toward continuous deployment and become more involved in thinking about the product. The safety and speed that's gained is seeming to result in teams that stay small. It's not for everyone, and caused attrition early on, but talking about these practices during interviews has attracted the right people.

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

#87

Post by dingaling »

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…

> does anybody really think a human can run through 800 test cases better than a computer can?

Of course not. But automated tests are just the entry ticket to the release process.

A computer can't replicate the irrationality, laziness and guile of a human end-user. That's what good QA engineers test.

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

#88

Post by DougWebb »

jboy55 wrote: post #70
arielweisberg wrote: post #37

Earlier quoted context omitted.

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…

I'm in full agreement. In practise, a manual QA team encourages Devs to throw shit over the wall and expect someone else to do some basic sanity checks they should have already done. By the time those are done, what the QA team theoretically could find gets shipped. Then, when its discovered in Prod, the QA team will get in the way of a speedy fix.

That's a management problem, not a problem with having a QA team. The top-level QA manager and the top-level Dev manager should both report to the CTO, and the Dev manager should be judged by how many issues the QA team finds. To keep things fair, the QA manager should not be rewarded nor penalized based on the number of issues found pre-release, and everyone should be rewarded or penalized based on the number of issues found post-release.

This keeps the devs incentivized to make sure everything works before the code goes to QA, and it keeps everyone incentivized to eliminate as many bugs as possible before release.

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

#89

Post by tostitos1979 »

dragonwriter wrote: post #24
minimaxir wrote: post #22

The stereotype that QA-is-pointless in Silicon Valley is persistent and actually annoying. There will always be issues that even the most comprehensive test suite will miss. Startups still glorify Facebook's "Move Fast and Break Things" without noting that Facebook has backpedaled from that. After all, people expect startup software to have issues, so what's the harm? Technical debt? Pfft. Engineers are not the best…

The QA function is not pointless. Whether a distinct QA team is the best means of performing the QA function is, however, a separate question.

I was on a large, fast moving project, with dozens of components. Some genius decided that devs will do all QA, automated testing, blah blah. It was a disaster.

The insane deadlines required devs to write lots of poor-to-average quality code (tried code reviews and peer programming ... no time for that so it fell on the wayside). The automated testing done by devs was terrible but understandable. If you are up until 2am hacking out code (without any precise requirements), then why bother with testing? We ended up having one -somewhat- central component that had "gating tests". Everyone stuck their tests there. That made things worse since that one component was the one that kept seeing failed tests. The PMs did frantic "user-like" testing before demos. You can imagine how fun that was.

In my opinion, the decision to not have a dedicated team of testers was the big mistake in all of this. When you have many teams, many components and no precise requirements, you need an independent QA team to coordinate and prevent people from passing the buck. In a time critical project (what projects are not time critical today?), you don't have precise requirements and devs have to "sling" code. I accept this reality. But I don't except the "no QA will make you mature devs" stupidity. If I was being a mature dev, I would refuse to code until the requirements were clear. None of this 2 week agile-scrum nonsense.

Oh .. and one other big thing. The project was a cloud project that needed to be up 24/7 while we were developing it (for beta users). It was like going from one outage to the next. What a disaster!

So what I learned is this: not only have a QA team, but have a 24 by 7 QA team for the kind of project I was on. Note... not all projects are the same!

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

#90

Post by shostack »

ngoel36 wrote: post #23
Apreche wrote: 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.

It's impossible to ask engineers to do more work in a day - you can only change the work being done and/or the time you give them to do it. My guess is that they'll be asked to do more automated & sanity testing as part of their cycle, and as a result their timelines will be extended. Imho, this is the way engineering teams should be structured anyways.

> "It's impossible to ask engineers to do more work in a day - you can only change the work being done and/or the time you give them to do it."

False. If engineers are typically working 9-5 or 9-6, and you give them new responsibilities but keep existing deadlines and scope, it in essence has the effect of forcing them to work longer hours to get the work done (or else...).

Post reply on HN