Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Bug Programming Yahoo!

No More QA: Yahoo's Tech Leaders Say Engineers Are Better Off Coding With No Net (ieee.org) 216

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.
This discussion has been archived. No new comments can be posted.

No More QA: Yahoo's Tech Leaders Say Engineers Are Better Off Coding With No Net

Comments Filter:
  • by Dunbal ( 464142 ) * on Saturday December 12, 2015 @09:32AM (#51104621)

    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?

    • Did you get through TFS? The claim is that overall errors have been reduced but not eliminated.

      He could be lying, but if that's the counterclaim, then show some evidence for it.

      • by Dunbal ( 464142 ) *
        Trying to figure out facts in a joke. Lighten up, fella.
      • by Junta ( 36770 ) on Saturday December 12, 2015 @10:29AM (#51104779)

        While 100% was hyperbole, I think the point stands: if you remove QA then the number of *known* issues is going to go down. Whether your number of *actual* issues go down it's another matter.

        I view this as the nightmare scenario, management hears words like automated testing as part of CI and then assumes automation has taken care of everything and they don't need the QA people. When the QA people's input into the issue tracker goes away, the numbers of issues in the graphs go down. Management gives themselves a pat on the back as a problematic metric has improved, without too much thought as to why.

        • Re: (Score:2, Redundant)

          by phantomfive ( 622387 )
          I can give a counter-idea: in my first job, I didn't have QA. It was up to me to make sure my own code was quality enough before releasing it, and that aspect terrified me enough that I did learn to write quality code (which basically means you are testing your own code thoroughly, doing your own QA).

          Now, at the time I was working with programmers who were much more skilled than I was, and I learned from them. Yahoo is a much larger company, with a programmers of a more varied skill-set. It is not rationa
          • by rgmoore ( 133276 ) <glandauer@charter.net> on Saturday December 12, 2015 @12:21PM (#51105263) Homepage

            It was up to me to make sure my own code was quality enough before releasing it, and that aspect terrified me enough that I did learn to write quality code (which basically means you are testing your own code thoroughly, doing your own QA).

            The problem with testing your own code is that you're likely to miss entire classes of bugs. You can be very effective at catching the kinds of bugs you can think of, but those are always the easiest bugs to catch in the first place. The tests you write for yourself will never do a good job of catching errors in your assumptions about what the code should do, what kinds of inputs it needs to handle, etc. Catching those kinds of conceptual bugs really requires adversarial testing from somebody who isn't starting from the same set of assumptions.

            • by phantomfive ( 622387 ) on Saturday December 12, 2015 @12:34PM (#51105339) Journal
              Yeap. That's where pushing to live production is going to be your brutal tutor.....if you have cognitive biases that are hiding bugs from your psyche, then the system will show you to them (most likely in the most inconvenient time), and you will learn. It's harsh.

              You can get the same experience (but with less harshness) by giving yourself the goal to never let a bug get past you to QA. Then QA will be a kinder tutor that helps you learn.
          • by NormalVisual ( 565491 ) on Saturday December 12, 2015 @12:39PM (#51105369)
            I can give a counter-idea: in my first job, I didn't have QA. It was up to me to make sure my own code was quality enough before releasing it, and that aspect terrified me enough that I did learn to write quality code (which basically means you are testing your own code thoroughly, doing your own QA).

            I think it's always necessary to test your own code via unit tests and whatnot prior to letting someone else have at it, but I think it's also important to have that second set of eyes on it from a behavioral standpoint. Often we're too close to the code to really beat it up properly and subject it to really weird edge cases, and good QA people are quite adept at doing that. What I've found works pretty well is having the code go through QA, but still being held to some kind of personal accountability for it as well. Even if it's nothing more than your co-workers laughing at your QA bug reports and saying your code sucks, it's some more motivation to get it right the first time, and if it passes QA you have at least some degree of confidence that it works properly.

            Another thing I've learned is that the stereotypical animosity between dev and QA is counterproductive. It's much better to think of them as two parts of a team working toward the same goal, and it's beneficial to foster an environment where the devs actively encourage QA to break stuff instead of trying to blow them off all the time.
      • Re: (Score:2, Interesting)

        by Anonymous Coward

        He could be lying, but if that's the counterclaim, then show some evidence for it.

        I hold in my hand a bag containing a small, living, pink unicorn.
        What do you say? I'm lying? Well, if that's the counterclaim, then show some evidence for it.
        What do you say? You can't look in the bag? Well, my point exactly.

      • by sunderland56 ( 621843 ) on Saturday December 12, 2015 @12:27PM (#51105299)

        The claim is that overall errors have been reduced but not eliminated.

        But with zero testing, how would they know?

        • by cfalcon ( 779563 )

          > But with zero testing, how would they know?

          Don't even think about believing it. If removing test was a good idea, it would have been done years ago across the industry. You seriously think an entire profession is entirely needless? Like, even for a second?

          This is just some dumb scam to reduce corporate overhead to pump dem stox. You'd have more success firing the managers (another bad idea that has been tried).

      • by gweihir ( 88907 )

        "Number of errors" is a meaningless metric. You need to take severity, cost of fixing, cost of finding, and damage done into account. But MBA bean-counters cannot do that, as they do not understand anything they are "managing".

        • by cfalcon ( 779563 )

          They understand if you remove people from the payroll and claim it helps, that it makes the stock go up. Say "my production code doesn't need to be tested, I found all the bugs" in a mirror. What does that person look like saying that?

      • He could be lying, but if that's the counterclaim, then show some evidence for it.

        You're missing the OP's original point. It's difficult to prove anything if you've stopped measuring things.

        May be it's just me because I'm not a great developer, but I work that much harder to find bugs within my programs because I know that QA will always try harder than me to find any bugs that I let through.

        Furthermore, even if the number of bugs stays constant even without QA (which I very much doubt), without QA those bugs are going to be found many days if not weeks later than usual. And as a develop

    • by naasking ( 94116 )

      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.

      His argument is sound though. Testers don't always follow proper testing procedure, so you'll still get plenty of bugs passing through it, and it takes way too much time for this to feed back into the develop-test cycle. Better to spend all that QA time writing more automated tests of various types, which the devs can run themselves during their much s

      • A handful of ordinary dumb users and a smart sixteen-year-old with authority issues should be able to find enough bugs to keep the QA department busy for quite a while.
        • by lucm ( 889690 )

          You forget the team lead: an older woman who doesn't understand the difference between click and double-click and has to do all her testing with one of those laptops that has a virtual scroll bar on the trackpad.

      • by Junta ( 36770 ) on Saturday December 12, 2015 @10:40AM (#51104825)

        The argument is actually pretty bad. By all means add more automated testing and hopefully make the QA process smoother, but skipping it entirely (they fired the QA team) is a recipe for disaster, and the only thing they have to measure the effectiveness of this is the number of issues in their issue tracker, which was *fed* by the QA team. It's like a company firing all their warranty people and bragging about how their warranty claims have gone to zero. The filed issues may be lower, but that does not speak to the final product.

        Testers don't always follow proper testing procedure

        This is a double edged sword in my experience. The testers are using the software much like a human would, and they do unexpected human things like the end user would be doing. This particularly helps identify usability issues, which isn't really an automation sort of thing. It's also a lot of fuzzy stuff that is usually not specifically laid out in the spec.

        robustness towards matching the spec

        Sometimes single minded march toward matching the spec is a bad idea, because the spec is bad and needs to be revisited. Sometimes this plays out in development, and sometimes this plays out in QA when humans clearly have a harder time with the interfaces than expected. Also generally speaking for me a spec is pretty high level, open to interpretation, and refined throughout the process as the details of the implementation get fleshed out.

        • by naasking ( 94116 )

          By all means add more automated testing and hopefully make the QA process smoother, but skipping it entirely (they fired the QA team) is a recipe for disaster, and the only thing they have to measure the effectiveness of this is the number of issues in their issue tracker, which was *fed* by the QA tea.

          Which can be replaced by an easy issue submission process embedded in the program itself. Combined with a program trace of the user's actions, which Yahoo already uses as part of its distributed architecture,

          • by Junta ( 36770 )

            I wasn't so much about unexpected data input, but a user not knowing what the hell to do to get what they want. Functionality they don't figure out.

            Which can be replaced by an easy issue submission process embedded in the program itself.

            Yes, just make your users your testers, great idea. Maybe for a community free effort, but for a commercial deliverable, that's *not* where you want things to be.

            humans having a hard time using an interface, this is generally obvious to the developers too

            Developers are frequently not very much in tune with their target end user perspective. Hence why I see my fellow developers get frustrated with testers and even clients, wondering why the users can'

            • by naasking ( 94116 )

              Yes, just make your users your testers, great idea.

              User acceptance testing is the only meaningful testing of this sort. There's no way around it really. Black box testers don't have the domain knowledge that end users have, nearly any usability feedback is practically meaningless. How could a blackbox tester possibly really know whether a particular screen layout, or information organization, would make sense to an end user?

              Developers are frequently not very much in tune with their target end user perspecti

      • by creimer ( 824291 )
        Black box testing is where the tester has no idea what the code inside the application does and test the application like a regular user. White box testing is where the tester knows what the code inside application does and test the application like a programmer. In an ideal development environment, programmers write unit tests to white box test their own code and testers black box test the application as a whole.
      • by cfalcon ( 779563 )

        Unit tests are not functional tests. You NEED functional tests, you SHOULD HAVE unit tests.

        Also, why do you think TEST can't follow test procedures, but somehow SOFTWARE will?

        This is just a stock pump and dump thing.

    • by Lennie ( 16154 )

      The summary sucks, read the article:

      They got rid of the QA team and made the programmers create more unit-tests (this is key).

      Because the computers made less mistakes than the QA team.

      • My experience in a recent project is that the main source of real bugs (those that take a good bit of looking-for) was in the integration phase. Of course I had issues with the overall design of the thing. Seemed like race conditions were always popping up--mainly when you got it out of the development shop and further down the pipelines. (Note: I was doing a QA function at the time, so maybe my bias is showing.)
      • They got rid of the QA team and made the programmers create more unit-tests (this is key).

        Of course that's not really true, either...

        From the QA team: "Some started working on automation [for testing], and they thought that was great—that they didn't have to do the same thing over and over."

        So really all they did was move their good QA folks to different departments, where they are now writing QA tests, but just don't get called QA engineers anymore, so Yahoo can get PR with nonsense stories like thi

      • They got rid of the QA team and made the programmers create more unit-tests (this is key).

        The programmers should have been writing unit tests all along.

        .
        How is that a justification to eliminate QA?

    • So I take it Yahoo have also eliminated employee sickness by abolishing sickpay! What a bunch of *****!
    • Well, this is a special case where the plan is reasonable.

      I mean, what good is QA when you don't have any end-users?

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

  • by Razed By TV ( 730353 ) on Saturday December 12, 2015 @09:38AM (#51104643)
    If your QA people are adding to the problems, you are probably doing it wrong.
    • by Teancum ( 67324 )

      I couldn't agree more. It sounds like they were more interested in the QA process than actually having people as a part of the overall software development team that try to break code and find flaws.

      There are multiple ways to accomplish the goal of finding bugs, where the worst place to have them reported is by customers. Is that what Yahoo is hoping for now?

    • If your QA people are adding to the problems, you are probably doing it wrong.

      .
      This.

  • by mikelieman ( 35628 ) on Saturday December 12, 2015 @09:39AM (#51104649) Homepage

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

    • by JoeMerchant ( 803320 ) on Saturday December 12, 2015 @09:50AM (#51104667)

      Where are my mod points? TDD is not the elimination of test and quality assurance, it's the procedualization / automation of it - along with driving it further forward in the product development cycle.

      To do TDD, you need less (or no) QA people at the end, and more QA work in early development. If you choose to do this by firing the QA department, you probably are getting your product to market slower. If, instead, you transition the frustrated programmers who have been stuck in QA since graduating into design, implementation, and maintenance of automated tests for the project, you're probably winning big.

      • by TWX ( 665546 ) on Saturday December 12, 2015 @10:33AM (#51104799)
        I very much doubt that they were smart enough to begin the transition to TDD before they eliminated their QA department.

        I worked quality assurance at a very-much test level without really delving into code. Programmers can be effin' stupid at times. I was testing daemons for communications protocols. I took four approaches. Verify that it does what it's supposed to do per RFC. Investigate the behavior when confronted with stale RFCs. Investigate the behavior when it's confronted with non-RFC input that is commonly available in end-user applications (ie, non-malicious incorrect use), and investigate the behavior when malicious intent is used. I can tell you that programmers working on these protocols wrote them to current-RFC only and that they were quite upset when testing obsolete commands from previous versions of RFC broke things, or when the third-party applications sent stuff to the daemons and broke them. I would have been understanding if the software had failed gracefully, with a warning or a 500 code or the like, but when sending obsolete POP3 commands to a POP3 daemon causes it to crash hard, or when encoding an attachment with Mac BinHex instead of MIME makes it crash, both of which were user-selectable options in then-popular Eudora (the client that the company itself used) then there's a big problem. I didn't even have to get to the level of malicious testing things were so bad.

        The point of a good quality assurance tester is to concoct out-of-the-box but plausible tests to try to break it. It has a lot in common with Security; it requires a degree of white-hat maliciousness and a need to use other kinds of experiences from other disciplines to devise the scenarios to use. It also requires the tester to have good communications skills as they may have to work to convince the development team that what they've found actually is a problem and being too antisocial or too introverted might not get problems corrected even if they are important and are discovered.

        Yahoo is doing a hell of a job in convincing me that they're really not worth paying attention to anymore. They are taking a position that is risky and is arguably excessively risky relative to the size and position of the company.
        • It also requires the tester to have good communications skills as they may have to work to convince the development team that what they've found actually is a problem and being too antisocial or too introverted might not get problems corrected even if they are important and are discovered.

          This is important. I generally take the attitude that the QA people aren't idiots, and I assume from the start that whatever they bring me is in fact a problem until I discover otherwise. If there's a disagreement o
      • by Junta ( 36770 )

        you transition the frustrated programmers who have been stuck in QA

        Most traditional QA people I deal with are not programmers, they represent roughly the level of skill of what real end users would be.

        you need less (or no) QA people at the end

        If you have *no* QA people at the end, you are putting way too much faith in your automated testing. It's true that in practice the 'end' QA goes smoother when you have automated testing in CI, but the tests are not perfect and the real world will involve real humans and you need real human perspective that isn't up to their eyeballs in the implementation. When you build t

      • by lucm ( 889690 )

        To do TDD, you need less (or no) QA people at the end, and more QA work in early development.

        Wrong. You need less QA people at the end and more *BA* work in early development. Those are two totally different things.

  • by coop247 ( 974899 ) on Saturday December 12, 2015 @09:41AM (#51104651)
    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"
    • A Bullshit Bingo gold mine.

    • 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"

      Lol, no shit...I'm going to print this out and frame it. And if anyone in my office ever utters any of those phrases, I'm going to hit them over the head with the framed print.

  • Can't wait until Boeing and Airbus do this!

    • ISO 9000 has been driving "quality" into the design phase of the project for 20 years. If you've stopped "testing quality into the product at the end of development" then, you've adopted QA tech that was mandated in many industries in the mid 1990s.

      • Re:Awesome Idea! (Score:4, Insightful)

        by TWX ( 665546 ) on Saturday December 12, 2015 @10:41AM (#51104829)
        They still do a lot of end-stage testing though. Pressure testing, structural testing, failure-mode testing, load testing, load-shift testing, strike testing, and probably all other manner of tests. They do perform a lot of tests as they develop but that's no replacement for the final-stage testing that confirms predicted behavior or verifies that systems integrate as expected.

        To pretend that there's no end-stage testing is simply ridiculous.
    • Put another way, Boeing and Airbus have been doing this for a very long time - when is the last time a passenger jet design was constructed and flown by a "test pilot" to shake out the bugs and check for nasty handling behavior?

      • by mikael ( 484 )

        With the fly-by-wire systems, all the testing can be done with mock-up flight decks and flat-screen displays. The funny thing is that glass cockpit displays only were introduced because it was cheaper to simulate expensive instruments using computer graphics, but the pilots preferred the flat screens to the actual instrumentation.

        • As an ex-Boeing guy, one of the driving forces behind the whole glass cockpit thing was the versatility of the system- the fact that a given area on the dashboard (where space is always at a premium) could be used to display anything, ie. whatever was most needed or most useful to the pilot at that moment. Infinite flexibility coupled with easy customization was a huge step forward.

          Don't need the engine temp readouts at the moment? Use the same space to display the oil-pressure readings or the intake temps

      • by Teancum ( 67324 )

        when is the last time a passenger jet design was constructed and flown by a "test pilot" to shake out the bugs and check for nasty handling behavior?

        You are aware that there still are test pilots who fly prototype commercial jet prototypes and often even push the limits [wired.com] of what those vehicles can do. They test sub-systems [youtube.com] for potential failure modes and do other things to "shake out the bugs and check for nasty handling behavior" under extreme conditions that likely would never actually happen on a routine flight.

        Admittedly the engineers of these vehicles have a long history to draw from and they are doing mostly minor incremental changes with each new

      • by matfud ( 464184 )

        Every aircraft made by both companies is first flown by a production test pilot before delivery.

      • by PPH ( 736903 )

        Boeing takes every new airplane up on a 'shakedown flight'. I know. live right under their flight path (and I used to work there). I have an ADS-B receiver and I can see when they take off and turn right around to land again. Every once in a while, one flies over my house low and slow with the gear stuck down.

        Boeing's problem is that they don't do as much 'unit testing' as they used to. Slap it together, shove the pilot into the cockpit and go. If it comes back, deliver it. They are pretty good at making s

  • 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?

    • I expected this reaction. You just don't get it. Testing hasn't been eliminated, simply the silo. I've worked on a few tester-free teams and it's been an unbeatable experience.

    • By finding a bug that happens once in a blue moon when the stars are aligned, getting development to remove that bug and introduce two new ones that happen more often but can't be fixed now anymore 'cause, you know, release date.

    • If software engineers know they have a safety net to pick up their mistakes, they can get complacent and become less careful about making errors, so as to get their work 'finished' quicker. The best way to avoid bugs is not to write them in the first place, but learning the degree of care and atention required is hard, and people will often (maybe instinctively) try to avoid this difficulty if they can. The root is psychology and complacency/laziness.

      • The best way to avoid bugs is not to write them in the first place, but learning the degree of care and atention required is hard, and people will often (maybe instinctively) try to avoid this difficulty if they can. The root is psychology and complacency/laziness.

        Sometimes it's not laziness on the coder's part, but rather pressure from above. Even when using the most efficient development methodologies, care and attention to detail still take time. Some coders just don't have the cojones needed to t
    • by Sigma 7 ( 266129 )

      How is checking for bugs supposed to add bugs?

      It doesn't. Rather, it's the improper QA that either introduces bugs or causes them to remain undetected.

      Proper QA prevent stories like those found on The Daily WTF.

  • ... How 'bout Yahoo eliminates the management structure, i.e., the "Yahoo tech execs", that came up with this idea.

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

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

    • Pain for Yahoo? Or pain for their customers?

      Yahoo has the luxury of not being critical software. If there's a bug, people either work around it or use something else; when your product is given away for free, expectations are low.

      I wouldn't expect the same plan to work for things like banking software, or medical imaging software, where the consequences of a bug are much more serious.

  • 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.
  • 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.
  • 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
  • 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
  • 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.)
    • by creimer ( 824291 )

      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.

      That applies only to white box testers who need to know how the code works to write code-specific tests. Black box testers don't to need to know how the code works to test the entire application as a user would. The best black box testers are non-programmers, as they tend not to be linear thinkers and can crash the application in odd ways.

      • Actually I find it's true of black box testers too. I mean I've had issues where QA would black box test my code by just banging away at it but literally have no idea what the code was supposed to do. (and then write bugs because they didn't know the result actually matched the expected behavior.) This is things like code written to interface with a piece of hardware. The hardware returned an error which the software displayed and they didn't bother to trouble shoot the result from the hardware to find out
        • by creimer ( 824291 )
          Black box testing has a learning curve. Once you're familiar with the black box, you can refine your testing methodology. This happened to me as a lead video game tester. Nintendo is notorious for keeping all information about their hardware — including the dev kits — as proprietary. I found out a through a third-party development website that holding down two buttons on the dev console would dump debug info to the screen. Once I informed the rest of the department, we had an easier time getting
          • That's true however the company I work(not video games FWIW) for makes their own hardware and firmware internally and that stuff is all spec'd out and the guys that worked on it are a short 20 second walk. I've had to bring over QA people that have worked for us longer than I have over to the firmware/hardware department and show them that they do need to ask firmware/hardware if this is expected functionality and if they agree that software did what it should have. (More than once btw.)
  • 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
    • The developer had to fixed all the outstanding bugs for free, as management refused to payout their final milestone and bonus payments.

      I'm surprised that's all that happened. I would have thought there would have been some legal consequences.
      • by creimer ( 824291 )
        The video game was a flagship product. Both management and the developer needed to get it out the door to protect their respective companies. A public legal spat would have ruined everything for everyone.
  • 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.

  • That can work to a point, if you make the developers who wrote the code support it, too. That's getting in to devops territory. As long as you have a few developers who hate getting called in on the weekend to fix their broken shit and a manager who's willing to allocate some time to push for quality, it can work reasonably well. Your deploy process also has to support very easy rollbacks.

    I do a lot of maintenance programming and come in years after the original code was written -- my last project had C f

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

  • 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 si

  • by Tony Isaac ( 1301187 ) on Saturday December 12, 2015 @04:13PM (#51106525) Homepage

    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!

The reward for working hard is more hard work.

Working...