Slashdot Mirror
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.
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.
We're lazy as shit.
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, for the same reason professional writers need an editor. Someone else will see things that you didn't. Yes, they will.
Didn't Microsoft move to this model just before the Windows 10 upgrade, uh, issues?
https://www.windowscentral.com...
I've done development and QA work, and QA approaches testing from from a whole different perspective. The problem is context switching. It's difficult for a developer to approach a piece of functionality from the user's perspective (especially if they don't necessarily know all the parameters for how the functionality is going to be used) It takes time to switch out of that mode, and, in an effort to make the code perfect, you can come short of ever making the code good to begin with.
A QA engineer is going into testing with the mindset of an end user. What are they going to expect to have happen? What are they likely to do? What corner cases aren't worth exploring? It's useful for developers to have some experience in this, but I don't think it's reasonable to expect them to be experts.
In general, you want developers to spend time and cognitive effort making sure the code is functional and maintainable. Heaping on the cognitive load of completely switching gears and thinking like an end user isn't always the best use of their resources.
My Other Computer Is A Data General Nova III.
Longer version: NOOOOOOOOOOOOOOOOOOO.
I've been at places where managers get a variation on this lovely idea: Hey, maybe you would be more careful coders if you had to do your own testing. You're all so sloppy!
Oddly enough, this is mostly from non-coders, or folks without technical acumen.
Here's the deal: There ARE coders that claim to not make mistakes, and create bug-free code. Those are known as inexperienced or self-deluded coders, or folks only making one-off projects negotiating exact terms that make it not REALLY programming so much as configuring.
Even just from a simple level as just writing down words, if you've ever written a work longer than a couple of paragraphs, you'll virtually always reach a point where there's some subtle or stupid mistake you make without noticing it. Even VERY experienced journalists and writers need proofreaders on any serious project.
It's not a matter of taking your work seriously, or being unable to face responsibility - you're always going to be blind to the flaws in your own code, and although testing crews ARE expensive - they exist for many, MANY important reasons. They're cheaper than the same churn without a proper quality process. Sure, some of that effort may be being duplicated, or used badly - but few possibilities would be worse than expecting everyone to 'man up' and expect bug count to go down.
In other words - certainly, I can test my own code if you'd like, but I'm a VERY expensive testing staff member, and my perspective is going to cause me to overlook a lot of things - since it already 'makes sense' to me and I won't spot the inconsistencies a percent of the time.
Ryan Fenton
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.
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.
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.
Consider the plight of us semiconductor designers. You've got 10 billion transistors, all hooked up in designs by thousands of people and it all has to work together and if you get it wrong, you can't fix it. It has to be right. So hell yes, you test your own stuff before letting others see it. Then other people test it. Then you test their stuff with your stuff. Meanwhile there are teams of people putting it all together in lots of ways to try and break it.
The value in a design is not the design. It's the level of trust that the thing will work when you put it in a chip.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
This has to be the absolute worst idea I've heard in a long time. Decent developers generally don't make good testers. Developers don't test their own code well -- I suspect because they know the workflow and don't try enough out of the box things. I'm not suggesting that the developers should be absolved from testing, they should write unit tests, end to end tests and everything in the middle. I am suggesting that a second tier of testers is a huge improvement.
A corollary, if you ever have a good or great test person on staff, keep them. Sure, they'll piss off some of the developers but they are worth their weight in saffron.
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.
I stole this Sig
Not for their own code. Developers are lousy at testing their own code, because they handle the errors that they think of, and won't make the ones they don't.
I suspect that developers are even poor choices for testing other developers code, because they're less likely to make ID10T errors.
I think we've pushed this "anyone can grow up to be president" thing too far.
As a developer solo-managing a legacy codebase, it is still important to have various rounds of external QA.
The first issue is that the developer can be so far into the code that they can completely miss what is obvious or un-intuitive to a non-technical user. This may also involve legacy bugs or interactions with code they havn't written themselves.
The second issue is that the the spec itself may not have been fully defined, or what you have is the developer's interpretation of the spec, and this may require clarification or feedback once someone has seen the end result.
The third issue is that a developer will focus their attention on the things they consider most important. Sometimes the best way to achieve this is to just give a developer a list of minor bugs/features, which is a great way of focusing attention by clarifying the spec and letting a developer speed though a bunch of quick fixes which have a predefined spec (defining the spec is half the mental effort).
So in general a developer should be capable of doing a first round of internal QA on their own code, but a second pair of eyes is still occasionally needed, as the developer has a very peculiar set of perception filters.