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…
Yahoo’s Engineers Move to Coding Without a QA Team
91–100 of 188 posts
Re: Yahoo’s Engineers Move to Coding Without a QA Team
#92If this is working so well, why is there still no version of Yahoo Messenger—a core product—for either Mac OS X or iOS?
It looks like Yahoo Messenger for iOS was released on December 3: https://itunes.apple.com/us/app/yahoo-messenger-chat-share/i... And apparently there's a native OS X client coming, as well: http://mashable.com/2015/12/03/yahoo-messenger-is-back/
Thank you! I apologize for being 8 days behind on this. :)
It's still mystifying that there was no iOS or Mac version for such a long (albeit temporary) period of time.
Also mystifying that I apparently deserved a -4 for this comment. Seems valid to me to note Yahoo not having an app on iOS or Mac OS for well over a year.
Re: Yahoo’s Engineers Move to Coding Without a QA Team
#93Earlier quoted context omitted.
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.
I think we must be misunderstanding each other. Developers are human. (At least, I think we are.) We respond to the incentives and structure of the environment in which we're developing. A culture of "throw crap over the wall to QA" naturally creates an incentive for quickly writing up features, without balancing that with robustness, because finding the problems "is QA's fault". A culture of "the devs are responsible for the quality of their code" produces better code. The way to treat the devs well is to have the QA folks go off and create or bring in easy-to-use automated testing and CI frameworks, to make it easy for the devs to do the right thing.
This is not a new observation - it's been happening over the last 10 years. see, for example, http://blogs.forrester.com/mike_gualtieri/11-02-17-want_bett... or http://product.hubspot.com/blog/the-classic-qa-team-is-obsol... and, while it's from 2007, http://googletesting.blogspot.com/2007/03/difference-between...
Re: Yahoo’s Engineers Move to Coding Without a QA Team
#94Every agile story should have a testable completion point, agreed upon by development and the customer. If whether or not the story is "done" is vague and arguable, it's not good enough to do.
One of the big problems here, and where QA professionals can add real value, is defining that "done" point. Customers are often not very good at it. Their idea of what they want is too vague. They want developers to just build something, and they accept or reject it when they see it (and fault developers for not building it right).
But really, all story completion criteria should be testable, and developers should be able to demonstrate the tests. The job of QA shouldn't be to test, but to make sure the developers are actually testing what they claim to test.
Re: Yahoo’s Engineers Move to Coding Without a QA Team
#95Earlier quoted context omitted.
Please let me tip a name for that: "Volkswagening" - assigning the quality check to the production team.
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.
Re: Yahoo’s Engineers Move to Coding Without a QA Team
#96Earlier quoted context omitted.
> 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.
I think we must be misunderstanding each other. Developers are human. (At least, I think we are.) We respond to the incentives and structure of the environment in which we're developing. A culture of "throw crap over the wall to QA" naturally creates an incentive for quickly writing up features, without balancing that with robustness, because finding the problems "is QA's fault". A culture of "the devs are responsibl…
> Developers are human
So are Q&A people. They are the developer's teams members not their minions.
> We respond to the incentives and structure of the environment in which we're developing. A culture of "throw crap over the wall to QA" naturally creates an incentive for quickly writing up features, without balancing that with robustness, because finding the problems "is QA's fault". A culture of "the devs are responsible for the quality of their code" produces better code.
I'm wondering why the presence of a Q&A team would in any way change the professional responsibility of developers to create correct, testable code. If your developers have developed a culture of "throw crap over the wall to QA", then that's on the developers.
> The way to treat the devs well is to have the QA folks go off and create or bring in easy-to-use automated testing and CI frameworks, to make it easy for the devs to do the right thing.
That is not really the function of QA. Developers need to use proper testing tools on their own, but QA has its own function beyond just testing the code. They also test the assumptions and specification that the "business" ask the developer's to code. They look for bugs that go beyond what a certain set of test criteria instructs. It is also important to supply Q&A with tools to do fast, automated testing. Developer tools are not the function of Q&A.
Q&A has a job to do, and its irresponsible for Developers use them as a substitute for their responsibilities. As an example from other industries, safety is not just the Safety Officer's problem.
// I've been equal years developer and system admin working with good and bad Q&A people
Re: Yahoo’s Engineers Move to Coding Without a QA Team
#97Totally buy they could reduce actual errors that matter. I've worked with many a QA who would get bent up over a detail outside of the spec that didn't really matter, and where all QA testing was manual. Coders (good ones) are well equipped to automate processes, and to do so quickly, and this extends to integration testing.
>I've worked with many a QA who would get bent up over a detail outside of the spec that didn't really matter, and where all QA testing was manual.
This is where you need management (or someone from the product side) who can set priorities, where needed, and put and end to pointless side-disputes that can and do crop up.
Re: Yahoo’s Engineers Move to Coding Without a QA Team
#98TL;DR: They fired the QA team to save money. Then they made the engineers do the QA work for no extra pay.
Nope, they did not. And no, they didn't
Source: I work there.
Re: Yahoo’s Engineers Move to Coding Without a QA Team
#99Surprised 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…
It sounds like there is some opposition between automatic tests and QA. But those do not have to be opposed - one can have both. In fact, for many types of software I don't see how you can avoid having both. The only choice you have who is doing your QA - your employees or your end users. Maybe Yahoo can afford the latter. But for some companies it would be a disaster.
Re: Yahoo’s Engineers Move to Coding Without a QA Team
#100Earlier 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. 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...).
Sure. But that's never sustainable.