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

111–120 of 188 posts

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

#111

Post by smithkl42 »

Our approach - in a much smaller company - is that all stories should have automated tests before they head off to QA. QA's job is to make sure that the story in question works correctly, it's not to find regression bugs. If QA finds a bug in the story, we write a test to catch that before we resubmit it. Over time, we have enough tests at all levels of the system that QA doesn't generally need to worry about regressions: just making sure that the latest story works as advertised.

This approach allows us to stay agile, with small, regular releases, while also making good use of what QA folks are actually good at.

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

#112

Post by clock_tower »

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…

Healthcare. Many companies developing medical software require two layers of QA (programmer review and QA; then a separate QA team) before release. "Works for me" is not appropriate when the "me" in question is not a subject-matter expert, and the subject matter is potentially deadly.

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

#113

Post by fein »

serge2k wrote: post #84
pc86 wrote: post #44

Earlier quoted context omitted.

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.

Pagers? Now it's just a total violation of work life balance through Slack.

My phone has never been so loud.

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

#116

Post by shostack »

ngoel36 wrote: post #100
shostack wrote: post #90

Earlier quoted context omitted.

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

Sure. But that's never sustainable.

Not sure about that. Many companies have successfully creeped up the responsibilities of people while keeping their pay the same. Add a few tasks here and there, tell them that this will look great come their review, but then lead them along.

Not saying this is good or that the practice doesn't result in increased turnover, but that doesn't stop companies from doing it with some success.

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

#117

Post by serge2k »

rifung wrote: post #31
Xyik wrote: post #26

Surprised that people are finding this unusual, in web/mobile anyways. In my experience most engineers do some level of QA themselves, particularly in start-ups < 1000 people. In what ways does an engineer being their own QA negatively impact the company?

Yup me too. At AWS we didn't have test engineers either. Everyone was responsible for testing their own code. We didn't even have SREs, so everyone was also on call. This just meant that everyone made sure they were writing well tested code before it got released because you didn't want to be the guy who made yourself, or worse, your coworker have to fix something at 3am. Of course I can see how this could be bad too…

> This just meant that everyone made sure they were writing well tested code before it got released because you didn't want to be the guy who made yourself

ha, yeah right.

What it really means at Amazon is build your service then bail for a new team before you have to maintain it.

Exaggeration, but somewhat true. I have a friend there now who has an oncall rotation that's split into day/night. nighttime oncall basically means you are working graveyard this week. Of course that is really because that team should have a proper support staff, it's a vital service.

Amazon, to me, is the epitome of a company that combines dev/qa/support because it's cheap rather than because it's actually good.

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

#118

Post by serge2k »

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

Nah, you write the code you write the tests.

Then you do a code review and make sure that the reviewer examines the code for missed cases.

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

#119

Post by csours »

mstade wrote: post #39

I don't think it's that cut and dry. I've worked in some places where the QA team was useless, meaningless red tape to get your stuff deployed. They wouldn't do much but sign off on deployment at some point , yet bore no responsibility if shit hit the fan. In these cases, they really were just an unnecessary cost and you learned pretty quickly to make sure your tests were in place, that you were testing for the right…

When testing, you are the headlights of the project. ... Testing is done to find information. Critical decisions about the project or the product are made on the basis of that information." [1]

I recently became a software tester, and I really didn't understand the role for quite a while. Is my primary responsibility finding bugs? Logging defects? Analysing requirements documents? Writing test scripts? Writing Status reports?

Answer: Do enough of each to fulfill your goal of gathering and sharing information with your management and dev groups.

If the software tester has problems testing, then the customer will have problems using it, and the company will have problems supporting it.

1. Kaner, Cem; James Bach; and Bret Pettichord. 2001. Lessons Learned in Software Testing. Wiley.

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

#120

Post by vkou »

DougWebb wrote: post #88
jboy55 wrote: post #70

Earlier quoted context omitted.

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 iss…

What will happen is that devs will ask their QA counterparts to report issues through an undocumented side-channel.

If you give an engineer a career incentive to optimize something, you'd be surprised how seriously some will take it.

Post reply on HN