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

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.

Comments

Fuck no

[Anonymous Coward]

We're lazy as shit.

Re:Fuck no

[Decker-Mage]

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

Should accountants audit their own bookkeeping?

[peterofoz]

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.

no

[cascadingstylesheet]

No, for the same reason professional writers need an editor. Someone else will see things that you didn't. Yes, they will.

Rotate

[sycodon]

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.

Re:Rotate

[Maxo-Texas]

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.

Re:Rotate

[Anonymous Coward]

That's not surprising, the two groups that are best for finding bugs are the power users and the completely incompetent. And the power users are likely not the same type of people that are doing the programming.

I've personally got a talent for breaking software by doing innocuous things that should have been tested for.

Re:Rotate

[ShanghaiBill]

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.

Re:Rotate

[quantaman]

Developers testing their own shit subconsciously avoid the shoddy parts.

The trouble with developers testing their own code is their objective is to finish the feature and move onto the next issue, not to find bugs.

A developer who spends 50% longer debugging their code is likely to get a reputation as a slow coder, if a bug shows up 6 months later it might not even get attributed to their change. And even if there is some potential blowback in 6 months time, it's hard to take that into account when your manager is breathing down your neck because the project is behind. I know I've taken heat in performance reviews for not finishing features quicker, I also know I've spent a lot of time fixing other people's bugs.

The reason for a QA department isn't that they've better at finding bugs in new features, they aren't. Rather the QA department gets to focus on the testing that developers have no incentive to do. QA also tests the features that developers don't work on, because every once in a while changing number of wings on a butterfly triggers a null pointer on the other side of the source tree.

As a retired developer and manager of developers..

[Maxo-Texas]

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.