Slashdot Mirror
No More QA: Yahoo's Tech Leaders Say Engineers Are Better Off Coding With No Net (ieee.org)
Tekla Perry writes: A year ago Yahoo eliminated its test and quality assurance team, as part of project Warp Drive, its move to continuous delivery of code. The shift wasn't easy, Yahoo tech execs say, and required some "tough parenting." But the result has been fewer errors because "when you have humans everywhere, checking this, checking that, they add so much human error into the chain that, when you take them out, even if you fail sometimes, overall you are doing better." And the pain wasn't as great as expected. Yahoo's chief architect and SVP of science and technology discuss the transition.
We were tired of being constantly bogged down by all these mistakes and bugs, so we got rid of the people who kept telling us about all the mistakes and bugs. Now our code is 100% mistake and bug free! Next step, get rid of our expensive experienced coders and replace them with cheaper outsourced coders with "equivalent" experience. We'll save so much money what could possibly go wrong? And the third and final phase of our plan is that in order to motivate our coders we will be paying a bonus that scales with the amount of code written. The more code you write, the better the bonus!
Don't you just love management?
Seven puppies were harmed during the making of this post.
A year ago Yahoo eliminated its test and quality assurance team
The perfect behavior for a company that is worth less than zero. (Subtract their shares of Alibaba from their market cap and you get a negative number).
If your QA people are adding to the problems, you are probably doing it wrong.
>It has also, he said, forced engineers to develop tools to automate the kinds of checks previously handled by teams of humans. An engineer might go through an arduous process of checking code once—but then would start building tools to automate that process.
I suspect they're too dumb to realize this and just tell everyone, "We're saving money and delivering better code using TDD"
Technology -- No Place For Wimps! Grateful Dead and Jerry Garcia Chatroom -- http://www.wemissjerry.org
Hilariously full of idiot speak:
"We forced excellence into the process"
"caused a paradigm shift in how engineers thought about problems"
"even if you fail sometimes, overall you are doing better"
//TODO: Insert catchy phrase
Can't wait until Boeing and Airbus do this!
How is checking for bugs supposed to add bugs? If you are not modifying the source code, it should be impossible to add bugs to it. Are they implying that these QA people were mistakenly listing features as bugs, and then the programmers were going in an removing features and replacing them with bugs?
Troll is not a replacement for I disagree.
Yeah we saw the result on Yahoo messenger for android...
A COMPLETE and UTTER Disaster.... They took a working app and turned it into CLUSTERF$%*K of a cartoonish joke.
NOW at least we know WHY they messed it _THAT_ much !
.
I certainly haven't seen an increase in the quality of Yahoo recently, indeed, the mail service's quality has taken a nose dive.
The supposed "success" of this experiment is probably due more to the Yahoo tech execs wanting themselves and Yahoo to look good for the sale of the company than anything else.
"We see our employees as children"
To me, software development is more plumbing than anything else. Take data from one end of a pipe, do something with it, store it somewhere, send it off somewhere else. That's where the engineering bit comes in. Problem is, every engineer has their own standard of building stuff.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
they're just making the programmers do their own testing. I'm sure the "tough parenting" consisted of "Ok Jimmy, now if we find bugs we'll fire and replace you".
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Pain for Yahoo? Or pain for their customers?
I don't care about the total number of errors. What counts, is the severity of those errors. I deal with a misspelled message. I can't deal with a system crash.
I believe that it is very important to have a non-coder to test software. As a friend put it:
If I print out a message saying, "Press the space bar to continue", the user will press every key except the space bar, in combination with ctrl and alt."
A coder won't do that. Coders are simply to smart to test.
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
Such as why the weather module is incapable of keeping track of what day of the week it is or what city it it supposed to show. It definitely shows some weather happening somewhere though. When the whole site doesn't just give up and give error messages everywhere, that is.
A group of programmers were presenting a report to the Emperor. "What was the greatest achievement of the year?" the Emperor asked. The programmers spoke among themselves and then replied, "We fixed 50% more bugs this year than we fixed last year." The Emperor looked on them in confusion. It was clear that he did not know what a "bug" was. After conferring in low undertones with his chief minister, he turned to the programmers, his face red with anger. "You are guilty of poor quality control. Next year there will be no 'bugs'!" he demanded. And sure enough, when the programmers presented their report to the Emperor the next year, there was no mention of bugs.
Holy fuck, do you know who you're talking to?!
That's Bill McGonigle! Not just any Bill, and not just any McGonigle, but the Bill McGonigle!
Now I don't know who he is or what he's accomplished, but with a name like Bill McGonigle, I just feel the need to show him a lot of respect. And so should you!
Makes perfect sense to me.
My doctor is always nagging me about heart care -- less carbs, less sugar, less fatty food, exercise more... nag, nag, nag.
A few months ago I stopped visiting my doctor. I'm much more relaxed now. So far, so good.
I don't see why QA is needed at all. All you need to do is use the Rust programming language. On its home page it says "Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety." It sounds to me like Rust means that all programmers will write perfect software because Rust won't let them write buggy code.
In the real world of physical objects I can't think of any engineering discipline that does not have some type of Quality review and Assurance built into the engineering process. WOULD you like to fly on an aircraft that was never flown by a test pilot first? Would you like to work or live in a building that did not have the design and calculations for its strength and stability checked independently? I am an engineer who began his career working with the Big Iron mainframes of the late 1960's and early 1970's and ended up doing local area network design and security in the early to mid 2000's. For my first 15 plus years I was doing Q&A for very large mainframe systems application programs that were under constant revision. Over that time I was the first person other than one of the programers who touched hundred of programs and not one of them was without major errors when I first saw it.
Once, in the mid 1990's, a new project manager who implemented new methodology and standards for the programmers cut my requested Q&A time from 6 weeks for a major system upgrade to one. He assured me that in the programs created with his new methods I wouldn't find any major problems. During only one hour of testing the very first program I produced over three detailed pages of major problems where the program either did not do things like it was supposed to or did other things that it was not, or sometimes just crashed. When I turned in my results the project manager didn't want to believe it, but I had documented everything and it took the programming team over a week to correct just those problems. Since there were a number of programs in this project and since my experience was the same with each, we did not release the new system to production for about eight weeks.
Accountants and managers hate to pay for testing and quality control, but when they stop doing it it always comes back to bite them in the butt.
Software isn't real engineering, it's just patterns on a screen. How much quality assurance do you need to make a pretty picture appear on a screen?
An obvious troll here, but I'll bite.
There is a real discipline of software engineering. I'll also note that engineers from other engineering disciplines can't just pick up a programming textbook and learn on their own the skills which are needed for proper software engineering either, but it takes a whole bunch of skills and discipline that often isn't even learned in a typical Computer Science curriculum.
Besides, if you think all software development is about making pretty pictures, you are also clueless about what computers actually do in the 21st Century. Most video game developers are not software engineers, although some do exist even there. Try telling the software engineers working at SpaceX or NASA's JPL that they are not doing real engineering some time... and you'll get an earful from people doing rocket science where a misplaced semicolon out of billions of characters in a code base can make an unfortunate bad day. The trick where JPL engineers were updating firmware on a vehicle sitting on Mars is something that took some real engineering.
That probably shows that you work on shite copy-everything spring bollocks and think is software. Do you work in a financial company?
No, he has the programmers improvising QA automated test to fix up his own mistake. But those tests are written with the same eyes, if they made false assumptions, then the test contain those false assumption because its the same team and same assumptions.
Plus since when has automated testing been able to spot even a tiny fraction of bugs?
If it did a mis-draw, would they use machine vision with aesthetic taste to spot it? Of course not.
Jay Rossiter is clearly an idiot with zero experience in developing software.
I was one of the top programmers in my company a few years back, I never ever wrote perfect code, or even code that was perfect after the nightly automated tests. To have written a test to spot the bugs, they would have to have had some crystal ball! If I didn't spot it, what hope is there that any QA automated test I write would spot it?
Dumb, the guys a idiot.
Which if you're a decent developer you find out reasonably quickly which people in QA have a clue and which don't. With bad QA I've found I'm way more likely to find actual bugs than the QA person will.(Which means I need to find bugs anyway.) Here's an example. I was working on a legacy product and QA filed a few bugs that the text of a few labels on a dialog were wrong. Easy fix, just go into the resource editor and change them. However after double checking I had to point out something that the QA person missed. The dialog didn't actually work. (I mean it was useless since you couldn't use it to search for anything.) Unfortunately in the end they just had me fix the labels (that was the product managers call) instead of actually fixing the dialog.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
My opinion on QA is that if you weren't capable enough to be a software developer then you weren't capable of being in QA either. Unfortunately it seems quite a few companies think that QA should be staffed with people who weren't up to being developers and pay accordingly. (This doesn't work and just annoys us developers.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
They claim they did this in 2 years. I have my doubts that any large corporate software organization would go from a traditional methodology to TDD in that short a time. It would take at least 6 months to get all the developers the proper tools and training (even if some of them know how, not everyone does, and making sure everyone knows how to use the tools that get pulled in takes time). Then you have the process changes and glitches - how do the tests get run, how does the notification get sent when there are issues, how does a dev get more resources when s/he needs them?
And then you have for cultural issues, like the obvious one - if I screw up, will I get fired? Will my manager/team leader get fired? If I raise an issue and someone overrules it, what happens when that issue turns out to be real? If something is taking longer due to unforseen problems, do the deadlines get extended, or does it turn into a death march?
And all this assumes that the management chain is all on board - all it takes is a few stubborn VPs to delay it for a year.
Too much double-checking just gets in the way. Not enough is a recipe for disaster. "None" is the extreme of "not enough."
The questions are:
* Will the limited quality-assurance work that developers are already doing by themselves be "enough"? Very doubtful.
* Will the developers and development teams have the desire and time/resources to "step up to the plate" and do the necessary QA work that needs to be done? My guess is "Probably" and "Who knows?"
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
My main experience with Yahoo is Yahoo Groups. Worst web app I've used on a regular basis. Pretty much nothing works as you might expect, and it certainly doesn't do it every time. I honestly don't know why they think it works.
If this is what the QA team could provide, they should have been jettisoned long ago. As should the development team. It's a miracle they are still in business.
On the minus side, this will be a signal to idiot managers everywhere that it's okay to nuke your QA team. 'The big boys are doing it, so it must be good'. Not unlike an 'open' office layout.... Gack.
Having been in the industry for over 20 years, and also having been in QA for 8 of those years, my experience says that when a company decides to eliminate their QA department, the company is circling the drain. When a company is looking to cut costs and there is very little to no fat to trim, the first target is often QA.
One company I worked for, a company of 35 people, cut 5 of those positions. Two of them were QA headcount, including the Director of QA. The QA department then reported to a then recently-hired Vice President of Engineering, which is a spectacularly bad idea! The company was acquired a little over a year after that layoff, and the new company eventually let go of all of those people a few months after the acquisition.
Another company I worked for laid off 70% of their workforce, which included the entire QA department. There were obvious bugs and mistakes on their web sites and web-delivered services for over a year after that layoff. They were eventually bought by another company about 2 years later.
So, it is my considered opinion that Yahoo is in serious trouble. I predict they will either be acquired or go bust within the next year.
And so went Yahoo silently into the night. Bell tolls for Yahoo.
TL;DNR version:
QA can be divided into different skill-sets, and some of these skill-sets come cheaply. You do get what you pay for though.
Long version:
Finding the wrong labels ("search here" mis-spelled) is a good task for someone who has a good eye for what looks good visually. You don't have to have a customer's or developer's eye for that. While this is something that people tend to either have or not have, it's a common-enough skill that you can use relatively low-paid, low-trained, or community-college-intern-level people who aren't on a track to become programmers do to it. Such talent command more than a McJob, but far less than a full-fledged QA person. You could pay a recent high school graduate with demonstrated experience doing this work $MID-TEENS/hour (higher in expensive-to-live cities) in most of the US and get good results and have a happy employee.
Finding logic bugs (search function doesn't work) takes a bit more brains. $MID_TEENS isn't going to cut it unless there are special circumstances (a family business, a startup where the "real pay" is an equity stake, a charity where the employee is willing to work for peanuts, etc.).
Finding user-interface design issues (where to put a search box, how many clicks does it take to do a search, etc.) takes someone who can see things through a customer's eyes. This isn't going to be cheap either. The bulk of the UI work should be done before initial coding (exception: If you are using any kind of rolling-prototype-that-becomes-the-product-over-many-iterations development technique, you will be tweaking or even re-designing the UI throughout, so plan accordingly). Having a UI person on board at this early stage is very useful, especially for a product that will see wide release. Having a UI person look over the product as it goes through development and testing to find bugs (where the implementation doesn't match the design, or where the design turns out to be flawed or infeasible) is also useful, but ideally by this time they won't have much to say other than "it's working as designed."
To some degree seeing things through your customer's eyes is an innate talent in the sense that it "come easy" to some people and it's "hard to teach" to others. Some programmers have it. Some don't. Some non-programmer have it, some done (non-programmers should at least be aware enough about programming and the tools the programmers are using to know what is and isn't feasible to do on a given project, or they might "demand" a seemingly-simple change that just isn't feasible).
--
The above is for a project that's getting large-scale release or where failure in any one area will be very expensive. In-house software projects, projects that are small enough that it's okay for the business if the project is a marketplace flop, etc. don't necessarily need this level of testing.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
When I worked at as a lead video game tester, a developer figured out the password to the bug database, zeroed out all the outstanding issues (including some serious show stoppers) for their game, and pushed for a code release meeting. This was done to stay on schedule for the milestone and bonus payments. Fortunately, management backed up the QA department and took a hard line stance against the developer.. Since the bug database got compromised, we spent six weeks re-testing all 3,000+ bugs. The developer had to fixed all the outstanding bugs for free, as management refused to payout their final milestone and bonus payments.
Yeah, f--k that noise.
I work with money now and code for fun. Suggest those with options consider similar alternatives. Life is a lot better.
..don't panic
We have a pretty good engineering test group. We do telecom products, so the test equipment is expensive. The engineering test group has most of the test equipment, and understand the application domain probably better than the developers. Plus (although we don't say this out loud) they're cheaper per hour than developers. They do white-box (make sure that if you configure x and y z happens) and black-box (poke the buttons and make sure it doesn't crash) testing.
It works out pretty well. We (developers) can bang stuff out, doing our best, but knowing it doesn't have to be perfect because the test guy is going to check it. And he costs less than a developer (and we can't give each developer a complete system with all the necessary test equipment). 90% of the time the fix or feature is good, 10% it isn't, engineering test finds it and kicks it back.
You stated this better than I could.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
What I'm worried about now is how other corporate minions will look at this and go. Great IDEA! While automated tests are good and should have been there before, they aren't the magic bullet in systems that recognize you tried that even before and change the result purposefully. In many cases, a flubbed web page or search results probably won't cost Yahoo! millions or even kill someone. In other industries it can be absolutely a disaster. Let's hope the minions think this time around. They're already chasing the Yahoo! CEO's act to reduce/kill work from home.
Management takes customer-reported problems very seriously.
And how seriously do they take ex-customers not reporting problems because they gave up in disgust instead?
I do a lot of maintenance programming and come in years after the original code was written -- my last project had C files with comments going back to the early '90's and K&R function declarations in some of the older headers. I don't recall ever encountering unit tests on any of the projects I've come in on, and the code is usually too tightly coupled to start adding them. Though if I do any significant new development, it's usually in the form of unit tested libraries that I can then integrate into the software.
I'm usually the one pushing for quality enhancements, because I hate getting called in on the weekend. I also hate deploying blindly to production. Often, the companies systems are also extremely tightly coupled, so setting up a test environment and a basic regression suite is also very difficult. A lot of the problems I see I attribute to very little actual accountability on the parts of the developers and designers. I think if they're the ones who end up having to support the code, there'd be a lot more consideration of quality in the design and implementation phases. That's probably what Yahoo's tapping into.
There are some drawbacks to that method of development, though. Poor quality deploys can definitely piss off your customer base. You also only find the bugs the customers find and report to you. A few projects ago, I was looking at a web front end a company put together for user management. For testing these, the software I was using at the time would act as a proxy to the server and completely bypass the javascript UI once you started playing back your tests. Unfortunately, all the data validation was happening on the client side. Naturally one of the tests I wrote was to try to enter a user with full administrative access on the system from an account that didn't have permission to create users. They system happily accepted it. I got some push-back from the developer when I reported it, because I was "making direct calls to the back end! No one's ever going to do that!" It's difficult not to be... hostile... in the face of that sort of ignorance.
Luckily for that guy, and for Yahoo, the sort if software I was using at the time is not readily available. You'd actually have to open up a web browser and go to a site on the internet to find something like that! No one's ever going to think to do that! And the sort of people who know how to do that sort of thing would never misuse that knowledge to steal billions from your company or embarrass them like that time with Sony. Or that other time with Sony. Or... hey, you guys remember that time with Sony? Yeah... that was a good one! Or that other time with all those people cheating on their spouses. I'm sure those were just flukes! So I'm sure this policy will in no way backfire on Yahoo!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Sounds like Bullshit, it IS bullshit.
Yahoo, soon to be sold off for parts? All that human pain, for what? So some shitlord can say "We're doing BRILLIANT"
Obvious troll is obvious.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Why is it called "test driven development"? Don't requirements drive tests? Then surely, by the transitive property, it should be called "requirements driven development".
A year ago Yahoo eliminated its test and quality assurance team, as part of project Warp Drive, its move to continuous delivery of code.
LOL Yeah, how's that working out for your bottom line?
All the places I've worked, when the end was nigh, QA was the first to go because they were going to start laying people off soon.
If you were me, you'd be good lookin'. - six string samurai
Oh wait...
You meant "safety net", not "internet". Now the summary makes sense.
I can see their point. The most important bug finder in software development, the one that cannot ever be properly replaced, is the original programmer. No one else can understand the underlying code well enough to replace them. And they can get lazy, with a big enough safety net they can get complacent and start to think that finding problems with what they wrote is someone else's job. But to write really good code, you also pretty much need an outside editor as well. There are many things that you will simply be blind to, that an outsider will spot straight away. It does not matter what you are working on. A Novel or an Application. At one point you need an outside observer to look over your work, but they are far less important than the original author doing so.
Troll is not a replacement for I disagree.
I've long since suspected that Apple functions this way. Strangely though, they do hire people to classify bugs as "will not fix" or "works as intended" even when things are clearly and seriously broken. Their developers continue to leave an ever expanding set of broken software in their wake, especially as concerns basic functionality and the OS itself, but also in senseless UI decisions. For example, the antiquated and still unreliable HFS filesystem, terrible NFS/SMB implementations, and the Finder which routinely loses files when performing basic operations.
So how is that working for ya Yahoo? They are circling the drain and about to sell off the Yahoo business. Yes siree, great management decisions at Yahoo. This would be funny if it were not for the fact that many people will lose their jobs from the management incompetency at Yahoo. Of course the higher level management will have their golden parachutes ...
I worked for one of the major Tech companies in Silicone Valley. The motto was, 'Fail fast, Succeed faster!'. All engineers were required to test their own code and document the testing plan. We used unit testing heavily and measured our test coverage. We also had functional and integration tests, we also had behavioral tests on the UI. Every week one engineer on the team would be responsible for release and they would re test every change in our staging environment. Now prod did go down a few time but in every case it was because we got out of sync with a dependency and not because we let a bug slip through.
I worked as a developer, and I was one of the rare ones who took QA feedback positively.
By and large, I got along well with QA. Simply because I acknowledged the fact that they helped me a lot in understanding better about developing quality software (at least UX wise). I was always driven to write code that pass QA, which I took as part of my work and pride.
However, not every developer shares the same sentiment as me. They went on to complain and remove QA, and take all that responsibility to them. Great, that's as good as you are the judge for your own court case. Since then, my employer fired all QAs, and ever since, quality reaching new "lows" every quarter.
...wasn't Yahoo getting out of the computer business anyways?
Back in the 80s, we wrote code and threw it over the fence to the users. If nobody complained, we assumed it was working fine! Ah, the good old days. What's old is new again!
cuz no-one uses Yahoo code.
My first programming job was working in a food manufacturing company as a junior programmer. There was a team of programmer/analysts. We knew the business of food manufacturing. We understood our own business. We understood the day-to-day jobs of employees who had to use our software. We tested our own code. There was no formal "QA" for the software. Part of the job was testing the code. If you didn't test your code, repeatedly had failures, your ass was fired. It's as simple as that.
Most pieces of software do not require a separate formal team to test it. All it requires are programmers who understand what they are doing, what business they are in, and how their software is going to be used. What the hell has happened to this business?
Woodworkers have more capability, domain understanding, and work ethic than programmers these days. A good woodworker tests their angles for trueness. They design their cut sheets to maximize wood usage and eliminate scrap waste. They test their joints for racking. They will sand every edge of a piece to make sure no blood can ever be drawn. They will make sure that every plane is perfectly level.
If you want to be a good programmer, get off your lazy ass and make an effort to understand your customer and the business you are developing software for. Test your own code and be intellectually honest with yourself while you do. If you need to automate, fine, but automate where it makes sense. Test things that make sense. If you do that, most of your code will be free of critical bugs.
If this was Yahoo's goal, then good for them.
Too lazy to find the link, but I seem to recall that NASA not only QA'd code for manned missions, but had two teams. Each team was composed of developers of equal caliber, and one team had no other job but making the other team "look bad" in the friendliest of ways--because it was of vital importance and potentially heart-breaking to an entire nation and even the world if something went wrong.
Now of course, Yahoo is not sending men to the Moon. It's understandable that you can dial it back a bit for a mere web site, but dialing it down to zero sounds pretty damned stupid.
Oh, BTW, if I'm wrong about how NASA's red vs. blue development work, I'm sure somebody will correct me. You might even say that this post is QA'd. Yahoo management will take everything I say at face value though. BTW, Yahoo, you owe me $1,358,345.23 for that back-end I wrote. You can trust me on that because I'm a developer and my contract specified no QA for any aspect of the project, which totally exists because I say so.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
In most cases I agree with you. Though some issues I've hit on certain projects, including at my current job, is when the software starts becoming really complex with a lot of dependencies. When you start making tweaks and changes to the foundations, you have so many things to understand and test that its just more efficient to do the process with multiple people in parallel. Some people write the test scripts, the test plans, the impact analysis, etc, and others execute.
Its simply about scaling people.
Risk homeostasis - you make much better brakes, and people begin to drive faster, take more chances in traffic and have nearly as many accidents as before. Put in better QA, and developers slack off their own efforts until the number of bugs that slips through is about the same as before. If QA doesn't respond to that, then they've become codependents, only helping programmers to be more slovenly and still keep their apparent productivity up, and keep their jobs.
But there are a bizillion better ways to deal with that problem than "Let's take out the brakes, or go back to really bad brakes." One of those ways is to, make risk severe but intermittent. In which case there's still QA - but it's NOT a safety net because at least 1/3 of the time (or 2/3 of the time) it isn't there to catch your particular errors, they are reviewing someone else's code quite intensely; and you aren't told when that is. (Even some of the time when they are reviewing your code, you aren't told, their reports to you are delayed, so that you can't figure out when they're watching for the moment and slack off.) Even the period they watch any particular coding team is randomly selected. QA still catches a lot of problems, saves a lot of money and embarrassment - but programmers can't relax or rely on QA to wipe their noses like a good codependent, so they remain vigilant.
Another way is to make the penalty for disappointing QA as visible and embarrassing as crashing the whole ball of wax. But highly visible rewards for safe coding are another.
It's very common in business environments for cooperation to happen at lower levels that frustrates the most important goals of top management. That apparently happened at Yahoo, and the response was to remove half of the cooperating parties permanently. The problem was real; but there are far smarter ways to deal with it.
Sounds like they doubled the workload of the developers, increased their risk, and didn't increase pay to compensate. Typical corporate bullshit. Last company that tried to do that to me was IBM, walked out on them on the spot. F/That.
I've always assumed that when you're writing the software you do a lot of testing throughout the process, but only a couple of weeks ago I was asked in all seriousness how I could know if something would work or not.
If you take the value of Yahoo and subtract the value of their Alibaba stock... it turns out the company is worth $0.
I would view eliminating QA skeptically if it were coming from a company that was making profits. Coming from Yahoo I'll take it as advice on what not to do.
FYI:
QA = Quality Assurance
Q&A = Question and Answer
A few years back (2009?) Yahoo rebuilt their site from scratch including their email. Several users complained about the buggy code and some even had emails that suddenly came up missing. One of their designers even was quoted as saying that people need to be kicked in the groin to appreciate good design. Many complained about features that were eliminated in the new design and that it looked too much like google and was full of bugs. Like others I got tired of the Yahoo's buggy interfaces and left Yahoo a few of years ago. From what I've heard from the few Yahoo users who didn't leave yahoo there are still problems and now they cannot get hold of anyone at Yahoo to report a bug or even unlock their account. It sounds like Yahoo doesn't listen to their customers and I think it isn't wise to drop QA.