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

101–110 of 188 posts

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

#101

Post by smsm42 »

tajen wrote: post #61
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.

Please let me tip a name for that: "Volkswagening" - assigning the quality check to the production team.

It doesn't even have to be intentional. If you write the code, you always have in mind some picture of how it should be used. That picture means you ignore the ways to use it which you not intended. So when the code is used in that way, it breaks. But you won't ever write a test for it because you would never think such usage is possible - exactly because you know too much about the right way of how it should be, so you start to think it's how it is.

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

#102

Post by smsm42 »

tajen wrote: post #95
vvanders wrote: post #65

Earlier quoted context omitted.

Haha, I'm going to start using that term. That's a great description.

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.

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

#103

Post by hofmann »

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…

I once worked in an organization that has 1.5-2x QA then dev. I now work in a place which has 1 QA for every 8 devs -- and there are far less bugs here then the other.

I think the reason is proper tooling, a culture of thorough automated testing, and ownership of code.

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

#104

Post by shortstuffsushi »

tostitos1979 wrote: post #89
dragonwriter wrote: post #24

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…

> tried code reviews and peer programming ... no time for that so it fell on the wayside

You don't think that could be related? If you had a sane development cycle, that may have helped. Having QA would likely have helped as well, but a healthy dev cycle is a good start.

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

#105

Post by fein »

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…

Have you ever worked for a fortune 100 company? The dev manager has probably never met the CTO. Im in this right now with my currrent job. I still keep my builds and test them longer than i should. Less broken shit gets through, but i regularly delay my qa ba's because of it.

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

#106

Post by dragonwriter »

tostitos1979 wrote: post #89
dragonwriter wrote: post #24

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…

Actually, it sounds like the main problem for the kind of project you were on was realistic timelines, not a QA team.

And I don't think an independent QA team helps to coordinate people and avoid buck-passing, IME, the more different teams are essential to delivering a piece of software to the customer, the more opportunities for buck passing, and the higher level of management the buck passing occurs at.

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

#107

Post by dragonwriter »

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…

> The top-level QA manager and the top-level Dev manager should both report to the CTO

For an organization with a single product (and, particularly, one small enough that the "top-level" QA and Dev manager are also first level managers), this makes some sense. Otherwise, this means that each product has no common level of technical management below the CTO, meaning it has no meaningful technical ownership.

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

#108

Post by ergothus »

I'm curious to find out if my expectations of QA are unrealistic.

I'd _expect_:

* Devs write automated unit tests galore, plus a smattering of integration tests

* QAs write some acceptance tests

* QAs maintain a higher level of broad understanding of where the org is going, trying to anticipate when a change in Team A will impact Team B _before_ it happens. They also do manual testing of obscure/unrepeated scenarios, basically using their broader knowledge to look for pain before it is felt.

The above hasn't happened anywhere I've been (though each point HAS happened somewhere, just not all together).

One thing in particular I've noticed is that a good QA is a mindset that a dev doesn't share. Devs can learn to be BETTER at QA than they are, but I honestly think it's not helpful for a Qa to be a Dev or a Dev to be a QA - they are different skill sets, and while someone can have both, it's hard to excel at both.

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

#109

Post by DougWebb »

fein wrote: post #105
DougWebb wrote: post #88

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…

Have you ever worked for a fortune 100 company? The dev manager has probably never met the CTO. Im in this right now with my currrent job. I still keep my builds and test them longer than i should. Less broken shit gets through, but i regularly delay my qa ba's because of it.

So, not the CTO, but some shared higher-level manager. The point is that the QA lead cannot report into Development, and Development cannot report into QA. Both of those arrangements can lead to a bad actor stopping the other group from doing the right thing. (Eg: if QA reports to Dev, then Dev manager can force bad code to ship, and if Dev reports to QA than QA manager can prevent shipping and force Dev to waste time on excessive/pointless test code development that's not cost-justified.)

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

#110

Post by DougWebb »

dragonwriter wrote: post #107
DougWebb wrote: post #88

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…

> The top-level QA manager and the top-level Dev manager should both report to the CTO For an organization with a single product (and, particularly, one small enough that the "top-level" QA and Dev manager are also first level managers), this makes some sense. Otherwise, this means that each product has no common level of technical management below the CTO, meaning it has no meaningful technical ownership.

It doesn't have to be the CTO; as I mentioned in another reply my intent was that QA and Dev need to be equals in the reporting chain, rather than one reporting to the other. That can work at any scale; even on an agile team with one QA and one Dev, they both report to the same boss who's responsible for both sides.
Post reply on HN