Live data from Hacker News

Yahoo’s Engineers Move to Coding Without a QA Team

spectrum.ieee.org

151–160 of 188 posts

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

#151
post #148

This isn't surprising. Microsoft switched to this model a few months after Satya took over. For the majority of Microsoft teams it worked really well and showed the kinds of results mentioned in this yahoo article. Look at many of our iOS apps as an example. But for some parts of the Windows OS team apparently it didn't work well (according to anonymous reports leaked online to major news outlets by some Windows team…

> I in no way want to sound like a dk but as an engineer it is your responsibility to practice test driven development but that's not enough.

One of the things that put me off when it comes to TDD is that it has always been a bit like religion.

What matters is whether the tests exist, not when they were written. I'd even argue that writing a test first and then being constrained by that box is a bad idea. Write the most elegant code first, and then write tests to cover all paths. You're more likely to know the problem better after the code is written.

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

#152
If all your QA team does is run through a bunch of tests that could be automated, then by all means, automate the tests and get rid of your QA department. However, good QA folks have a valuable skill, which is that they think of interesting ways to break software. Not many programmers do this very well.

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

#154
post #120

Earlier quoted context omitted.

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.

The solution to this is to require a bug/ticket/tracking item as part of the change. Since QA knows that dev needs to create one anyway, they might as well get the credit.

Where this starts to break apart is that QA can get overzealous and file bugs for different incarnations of the same bug.

It's a bit of give and take.

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

#155

Earlier quoted context omitted.

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…

That sounds like a problem with lack of resources and bad planning, not just lacking qa. If you were to choose between a) hire 3 devs to offload your work so that you can focus on your tasks better, or b) hire 3 qa guys that will keep throwing back the shit you produce because you are overloaded. I don't think any qa would help in such a situation

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

#156
post #33
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.

You are correct! I'm a programmer at Yahoo -- deploying multiple times a day to production, with the confidence your code will work, feels great. Manual ("batch-release") deployments have been forbidden for over a year, which is a forcing function to change development process to allow deploying to production continuously multiple times a day. This requires robust test and deployment automation and for engineers to b…

Forgive the throwaway -- but how does Yahoo define "will work?" Ignoring the calls against the UX change of several years ago, your own user feedback pages at https://yahoo.uservoice.com/forums/207809 make it pretty clear that longstanding issues such as spam (the same ring of spammers has operated for multiple years as Ultimate Stock Alerts, PennyStockAlerts and ExplosiveOTC and others -- simple Bayesian filtering could have solved this years ago) and things like the fact that the ignore function (a pretty core piece of functionality) has never actually ignored users - merely greyed them out, but they still take up space on the screen.

My point isn't to be negative about the state of Yahoo Finance; you probably don't work in that department, and after three years of neglect, most of the users are long gone.

My point is that if an organization is going to rely on end users to report bugs, the organization must actually respond to those bugs. Sometimes the answer might be "No, we're not going back to the Web 1.0 UX." But ignoring the top bugs for multiple years suggests a breakdown in the feedback mechanism. If Yahoo doesn't care, that's fine, it's just business. But it seems more likely that Yahoo doesn't even know there's a problem, because there's no way for user feedback to make it to the developers.

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

#157
Today QA is not manual testing.

Today QA is talking with product/UX, taking the end user and customer perspective, wearing a quality head end to end over features an cross devices, doing explorative testing for stuff that does not make sense to a customer (mostly what's created by the inference of different features or cross device interaction).

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

#158
post #102
post #95

Earlier quoted context omitted.

To be fair the exact meaning of Volkswagening is to fake the behavior during official tests. Example: http://qz.com/515100/samsung-is-accused-of-volkswagening-its... Note that volkswagening.com was registered 20 days after the scandal, but is available for bid, if you want to do something fun with it.

VW lawyers would probably throw a fit if somebody actually used that domain for anything commercial.

Perhaps it could display different, positive content when accessed from Volkswagen IP addresses, to ensure they wouldn't find out.

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

#159
If you think about a QA team as your customer, as any downstream department in the work pipeline truly is, you realize that in order to make full use of them and to maximize your efficiency, you as a developer should write automated unit tests to cover the user stories or feature requirements, allowing QA to work on the nasty edge-cases.

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

#160
"What happens when you take away the quality assurance team in a software development operation? Fewer, not more errors."

And what happens when you close your eyes? Reality disappears?

Automated testing is a way to completely remove customer advocates out of the loop. Correct UX doesn't mean good UX and unless someone can automate the test of all the non-quantifiable qualities of good and intuitive they're gonna push loads of engineering driven interfaces to their users.

-shivers-

Post reply on HN