Slashdot Mirror

← Back to Stories (view on slashdot.org)

Should Developers Do All Their Own QA? (itnews.com.au)

Posted by EditorDavid on from the QA-for-IT dept.

An anonymous reader quotes IT News: Fashion retailer The Iconic is no longer running quality assurance as a separate function within its software development process, having shifted QA responsibilities directly onto developers... "We decided: we've got all these [developers] who are [coding] every day, and they're testing their own work -- we don't need a second layer of advice on it," head of development Oliver Brennan told the New Relic FutureStack conference in Sydney last week. "It just makes people lazy..."

Such a move has the obvious potential to create problems should a developer drop the ball; to make sure the impact of any unforeseen issues is minimised for customers, The Iconic introduced feature toggles -- allowing developers to turn off troublesome functionality without having to deploy new code. Every new feature that goes into production must now sit behind one of these toggles, which dictates whether a user is served the new or old version of the feature in question. The error rates between the new and old versions are then monitored for any discrepancies... While Brennan is no fan of "people breaking things", he argues moving fast is more beneficial for customers.
"If our site is down now, people will generally come back later," Brennan adds, and the company has now moved all of its QA workers into engineering roles.

7 of 299 comments (clear)

  1. Fuck no by Anonymous Coward · · Score: 5, Insightful

    We're lazy as shit.

    1. Re:Fuck no by Decker-Mage · · Score: 5, Insightful

      More like using their customers for beta-testing, just as with every other shop it seems these days.

      --
      "[I]t is a wise man who admits the limits of his knowledge or skill, and that pretending either causes harm." --Terry Go
  2. Should accountants audit their own bookkeeping? by peterofoz · · Score: 5, Insightful

    QA done right can add value to a project by rooting our ambiguous requirements and holding developers accountable. Developers are worried about a lot of issues like function, aesthetics, security, performance, scalability. Having QA work from the same specs to derive the functional tests from a different perspective can provide a huge value to developers. But you have to involve QA early in the game.

  3. Rotate by sycodon · · Score: 5, Interesting

    EVERYONE on your team should be a developer.

    But QA should come from that pool for one project. Swap them out for the next, etc.

    Developers working at QA know where the mistakes are likely to be.

    Developers testing their own shit subconsciously avoid the shoddy parts.

    This also keeps the team as one.

    It's like a platoon of Marines taking turns burning the shit.

    --
    When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
    1. Re:Rotate by Maxo-Texas · · Score: 5, Insightful

      As a manager, my best developers were not my best testers. And my best QA people couldn't have coded their way out of a paper bag.

      Our top QA guy and head of the QA department was an ex marine sergeant. Didn't know how to code. But he was a top notch tester who caught anything that didn't match spec's or that changed from one release to the next.

      --
      She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
    2. Re:Rotate by ShanghaiBill · · Score: 5, Insightful

      Developers testing their own shit subconsciously avoid the shoddy parts.

      They also tend to have preconceived ideas about how users will use the program that are very wrong.

      The first time I watched a videotape of someone using a GUI that I had coded, I kept screaming "NO, not THAT button!!!!", but it was a recording, so they couldn't hear. It was a traumatic and humbling experience.

  4. As a retired developer and manager of developers.. by Maxo-Texas · · Score: 5, Insightful

    This is dumb.

    QA people think like QA people. Developers think like developers. And developers can't bring a fresh eye to their own code.
    Heck, most developers can't even develop remotely comprehensive test data.

    There is some evidence in the nuclear and aerospace industries that having things checked twice results in people being lazier (because they think the other person will catch it).

    But for mainstream business developers, I've never seen them able to test as well as QA does.

    --
    She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.