Should Developers Do All Their Own QA? (itnews.com.au) 299
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.
Fuck no (Score:5, Insightful)
We're lazy as shit.
Re:Fuck no (Score:5, Insightful)
Re: (Score:2)
Exactly.
It is fine that every developer should be testing. But nobody should be testing their own code - it is just not effective.
Re: Fuck no (Score:2)
Re: (Score:3)
Its still not really "fine," at least not on any sort of large scale. Programming and QA testing are actually quite different skill sets. Certainly there's some overlap (especially if you want/allow your testers to try and find the problem in the code rather than just reporting it) but they're definitely not the same role.
Add on to that the fact that programmers generally command higher wages than testers on average, and you end up with paying more for people to do a job they don't want to do and aren't e
Rotate (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.
Re:Rotate (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.
Re:Rotate (Score:4, Interesting)
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: (Score:2)
Yea, I have a guy at work that I have check things. He always finds something. It’s annoying :)
[John]
Re: (Score:2)
Yes, and IT always tells me that they cannot fix it. They bounce the bug around between three levels of support, until I give up. :-(
Re: (Score:3)
That's not surprising, the two groups that are best for finding bugs are the power users and the completely incompetent.
I'd say that there are at least 3 groups. Some developers are also really good testers. Some power users are really good testers. And the totally incompetent also are brilliant at finding bugs.
And you really want your QA to include all 3 types, because they each find different kinds of problems.
Re: Rotate (Score:4, Interesting)
The incompetent person in your example is the developer who let the same order be sent 100x.
It's normal to refresh or try again when a page hangs. Or do you sit there for several minutes before you try again? At the least they could deactivate the submit button once clicked, the right solution is an order token that is only accepted once.
I bet you only press the cross-walk button once too. Wouldn't want to break the signal!
Re: (Score:3)
I'd say a good example that the incompetent manage to find where they ran the installer twice in parallel.
Everyone else who was in testing ran the installer just fine, and started testing the software. Later on it went out to a limited release of customers... next day I had a report of some bizarre installation failures. Some idiot had downloaded the installer, double clicked, and then since the window didn't open up fast enough doubleclicked it again. Then a competent person would have realized the 2nd set
Re: (Score:2)
Is your employering hiring? ;)
Re: (Score:2)
And my best QA people couldn't have coded their way out of a paper bag.
Then who wrote your QA test scripts?
Re: Rotate (Score:2)
Also it isnâ(TM)t immediately obvious that something is wrong, since you have been at it too long or that your interpretation of things wasn't right. Other issues include trying to to prioritise doing code or testing. Usually they end up conflicting.
At the same time smaller organisations need to be more creative on how to reduce bugs, due to lack of manpower. Sometimes the cost is more bugs, sometimes reduced features or some other compromise must be found.
One thing I would push for at minimum is conti
Re:Rotate (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.
Re: (Score:2)
A programmer doing QA:
*runs code*
"Oh c'mon, no one would ever do that. I'm doing this instead."
*marks as tested*
Re:Rotate (Score:4, Insightful)
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.
Re: (Score:3)
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.
...and then, after it goes into the field, there are STILL one or more Errata that follow, with nice things things like "Oh, the SPI Enable doesn't work when PD20-23 are configured as SPI2"...
Re: (Score:2)
No matter how good the design and the testing, it never survives first contact with a customer.
Re: (Score:3)
Re:Rotate (Score:5, Insightful)
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.
Re: (Score:3)
their objective is to finish the feature and move onto the next issue
Your feature isn't finished until it is bug free. If devs don't get credit for completion until the QA is signed off, they will make a better effort to get it right the first time.
Re: (Score:2)
"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."
The real reason for a QA department is that developers are rarely allocated enough time to get something working, let alone working bug-free. By having a separate group, whose sole function is testing, then that guarantees - *mostly* - that the testing gets done.
Yeah, there are issues with developers not being
Re: (Score:2)
EVERYONE on your team should be a developer.
Just because QA should automate the test, doesn't mean the same skill set should be used for developing and QAing. Specialize or be bad at everything.
Developers testing their own shit subconsciously avoid the shoddy parts.
Which is why QA shouldn't know which parts to test and which not to test. They should make their own assumptions about how things should work based on how the product is described to the outsiders. Which means they need to be external to the project.
Re:Rotate (Score:4, Informative)
Sort of. QA does development, but not on the project, they develop automated testing scripts and the like. The skill sets are different. A developer should do basic testing, but the developer is way too close to the code and is very likely to miss things. I see developers who assume no testing is needed, it was an obvious fix, and then it turns out to have bugs. Developers are often not good at integration testing, because they may have troubles seeing the big picture of how all the parts fit together.
QA can read the product's code certainly, they can be involved in the code reviews, but they shouldn't develop that code either. For a good QA person, testing, creating the test plans from the functional specs, automating the tests, and so forth, is a full time job in itself. In a lot of ways it is harder than development.
Every time I have seem companies try to merge two groups or departments together it has not turned out well. And this cost saving measure won't turn out well either.
Re: (Score:2)
100% absolutely not. The skill sets of developers and quality assurance personnel very rarely overlap.
Re: (Score:2)
This.
Having developers do some QA will teach them what pitfalls to watch for. And make them better devs as time goes by. The argument that development and QA have different mindsets is both wrong and harmful. Devs need to code with eliminating bugs as a priority. Not just hope that QA will catch them before product release.
This is how it is typically done in engineering. A designer will hand their work over to another engineer to be checked. And the roles are swapped, so everyone gets to do both tasks. Th
Re: (Score:3)
Having developers do some QA will teach them what pitfalls to watch for.
Having developers do some QA as a training exercise is one thing, having them do actual QA for a releasable product is another.
The argument that development and QA have different mindsets is both wrong and harmful.
The argument that they have the same mindset is even more wrong because its simply not true, at least in general. Developers tend to need time to ponder a problem and then rapid-fire out lines of code until they have a working solution. A very binge-and-purge style of work. QA on the other hand needs to be methodical and repetitive -- exactly the kind of tasks that programmers ty
Re: (Score:2)
Fuck you, a competent developer already does qa, or we wouldn't release it to qa.
Wait, is it possible that QA didn't write the code, doesn't know its limits, and can put user testing on top of functional testing?
YES you fucking idiots.
Re: (Score:2)
You have a lot of anger, why?
If you would understand the power of good design specifications, you would see that useful QA (or DV for hardware design etc) does not start from the implementation but from these specs, the same as the designer.
It is obvious that you have no idea about how QA should work. There is a lot of very good information in this discussion thread about the subject (and some not so good), spend some time educating yourself.
Re: (Score:2)
What do you mean? QA write their tests against the same SRS, they need not know what the code does, they only need to know what requirements it needs to fulfil.
Comment removed (Score:3)
Re: QA sucks and developers do pass the buck (Score:2)
The user can and will find some obscure or previously unexpected way to break the application.
Bugs will continue to be found in production.
That said, I do extensive QA on any of my code that users will come into contact with. Lot of pokemon error handling. Though there are still bugs which crop up from time to time in product.
Re: (Score:2)
Good QA teams are what crappy Engineers lean on to explain why their shitty code is taking so long to release.
Re:QA sucks and developers do pass the buck (Score:4, Informative)
You need a series of gates and software/firmware/hardware has to pass through all those gates. The later a bug is found the more expensive it is to fix it. When the customer finds a bug it can be catastrophic; as in layoffs are going to happen because of loss of revenue. So find the bugs early, and make sure you've got all the gates set up.
- Developer must unit test the code - developer must to the basic test of flipping it on, making sure that something happens and that it does what the developer thinks it does. Finding and fixing a bug here is very cheap.
- Other developers must code review the changes; spread out the knowledge to more than one person, have other sets of eyes looking at the code, let someone point out where the clever change is breaking the design or violating preconditions from elsewhere in the project.
- QA must then test the feature; positive and negative tests. Run it for long periods, try to break it, compare it one by one to each requirement and specification. This can happen before all features are complete.
- QA then tests the integration; not just one feature but all of the features, so it's done once there's a code freeze for the release. Maybe it repeats some of the earlier tests, but it should run through a full regression, use it like a customer would use it.
- If it's applicable, do a full system test. End to end, from hardware board to back end server. Test different combinations. Finding a bug here is expensive; but it's still less expansive than having the customers find the bug.
If you still find bugs after that, then review how the bug slipped past, fix the gates, and do better next time.
Should accountants audit their own bookkeeping? (Score:5, Insightful)
no (Score:5, Insightful)
Re: (Score:3, Interesting)
Exactly. Some people are good at writing code. Some people are good at finding errors.
Modern writing has gone to hell compared to even cheap books written when I was young. As long as the word is correctly spelled it gets thru to being published. You read the atrocious error, get jarred out of the book, then resume reading.
In development, the atrocious error is a loss of all data on the screen, or the program hangs, or you can't update an amount if you come at the screen from one particular set of comma
Re: (Score:2)
"Some people are good at writing code. Some people are good at finding errors."
And what drives people is different. Some people get a thrill out of trying to break someone else's code or driving it to its performance limits. Other people like implementing new features. Or maintaining a codebase.
While I agree QA shouldn't be done exclusively by Devs, QA and Dev really need to work together and Dev needs to avoid a "throw it over the wall" culture. Help guide QA to write tests that provide optimal cov
Re:no (Score:4, Insightful)
Re: (Score:2)
That's really a small part of it. Mostly, it's that a fresh set of eyes will see things you didn't, even if they aren't as good at finding errors as you are.
Re: (Score:2)
The entire problem is that you remember what it is SUPPOSED to say, and so won't notice if 'tricks' is spelled 'ticks'.
Microsoft (Score:4, Insightful)
Didn't Microsoft move to this model just before the Windows 10 upgrade, uh, issues?
https://www.windowscentral.com... [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.
Re: (Score:2)
So does proofreading. Have you ever done any?
Re: (Score:2)
End users are idiots not experts. If developers are so clueless as to not be able to understand needs of users from the users perspective how the hell do you expect them to produce anything useful in the first place?
Do you expect the development team for Microsoft Word to understand what professional authors need a word processor to do? Do you expect the Excel team to understand how accounting works? Do you think that the person who works on the ANOVA plugin for Excel knows how it's used in statistical process control? Or analyzing cell growth patterns?
Short version: No. (Score:4, Insightful)
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
Re: (Score:3)
Coders should be responsible for the quality of their work, but the environment should support them. That means they should be given the time to write unit tests and perform code reviews. Code reviews are not just about reviewing implementation but reviewing the requirements to ensure the developer understood the requirements and implemented what was required. Code review is about ensuring that the unit tests for the code properly test the code. It is never a case of throwing new code over the wall to let
Re: (Score:3)
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!
But most likely, that's not even how it went down. What most likely happened was that they created toggles for every new piece of functionality. Then they wrote a script that would switch to the old version of the functionality as soon as an error with of the new functionality was detected. In other words, they wrote a safe-mode to relaunch their application under, every time an unrecoverable error or a runtime exception were detected.
And by itself, this is actually not a bad idea. It's one more way to prot
As a retired developer and manager of developers.. (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.
Re: (Score:2)
But for mainstream business developers, I've never seen them able to test as well as QA does.
I've been developing complex software systems for about 30 years now, and I couldn't agree with you more. We developers are the absolutely worst people in the world to QA our own projects, as we develop tunnel vision towards how the software is used; and we develop an unconscious aversion towards doing things that will cause problems for our systems.
I test my code extensively during development, but am still absolutely amazed at how quickly my customers find errors that didn't occur during my testing. My
Hell No! (Score:2)
Re: (Score:2)
The two teams do need to communicate. When quality goes down you can often trace it back to having bad communications. Ie, features aren't documented well, documentation wasn't written up front, and so forth. When you run across a developer who thinks QA is an adversary, then that's a problem that needs fixing.
External testing is necessary. (Score:3)
External testing is necessary to avoid a number of cognitive biases. Developers should do some degree of testing new builds, especially if the tests can be automated, but at the very least, you at least need roughly the software equivalent of a proofreader. Proofreaders are needed, not because a writer lacks the ability to understand basic grammar and spelling rules, but because the brain suffers from the opposite of NIH syndrome.
Does that necessarily have to take the form of a QA department? No, but this mostly sounds like trying to cut manpower or get around addressing flaws in the testing process. Another PHB trying to preserve his existence by pulling out pieces of a machine they don't understand.
QA is it's own step in development (Score:2)
Re: (Score:2)
QA also does things that developers don't have time for. QA is a full time job, and should be done in parallel with development. Ie, one day of coding, one day of unit testing, then QA may be spending a full week just on feature testing after that, then a week of integration testing, and several weeks of regression testing (hopefully automated).
That's nto counting documentation; ie, dev is writing specs and QA is writing test plans off of those specs and that's in parallel.
If theupper management thinks the
QA your own code? (Score:2)
I code in 3 different languages and write my own QA in each, but only because THERE IS NO QA department. Writing useful QA always takes way longer than initial coding of the script to do its intended purpose.
Coder's lament: "Why would a user *ever* do that?"
Because they are a different set of eyes and don't do the same things the coder does.
2 weeks ago I torpedoed my own QA handling an important script that had been working fine, QA 100% successful (so my report said). A "simple", backwardly compatible enha
QA is needed (Score:3)
QA is needed. However far too often QA teams are used as dumping grounds for Developers who cannot cut it
In my perspective the most complicated part in actually figuring out the tests. if you can figure out the tests it means you have nailed down the scope. if you can do that before you start coding the coding part is actually easy. However if you are only doing QA but not doing coding your coding skills will rust.
The best place I have worked had 2 scrums working on a project - Team Blue and Team Orange. For one release Team Orange was dev and Team Blue was QA. For next release Team Blue was Dev and Team Orange was QA. They kept switching around keeping both their Dev and QA skills updated but at the same time the context switch is easier to do at 6 weeks intervals than continuoisly during the day.
Depends on the context (Score:3)
"Test is dead" [youtube.com] was the keynote presentation of a Google Test Automation Conference six years ago.
My personal view is that if you are doing web development where your company rapidly & repeatedly deploys releases on behalf of customers, you might be able to get away with not having much of a QA department so long as the impact is low. If a problem arises it can be quickly fixed without much of a financial loss.
But if you are in a regulated industry, failure of your software will result in significant lost revenue while its being fixed, or your software is deployed only every few weeks or months by customers who do their own acceptance and integration testing, then you probably need to do more QA work & dedicated QA work upfront. In such scenarios the software producer and their customers may encounter significant losses and/or inconvenience because something faulty snuck through.
Re: (Score:2)
There is no ultimate process that is best for everyone. They might be right that when selling fashion, being able to make quick changes is more important to their customers than reliability. On the other hand, they do handle money and personal data, so discovering problems in production can have lasting consequences.
I think reactive QA is the real story here, not whether QA is a role handled by developers or by dedicated testers.
Stupid is as stupid does (Score:2)
I suppose if you donâ(TM)t care if your site and backend stop working one day then having devs do QA is fine. It all depends on your requirements and expectations. Oh, and who checks to see that toggle a doesnâ(TM)t affect code path c? End-users, of course.
Who needs QA? (Score:2)
Why? All my code compiles and runs perfectly the first time.
But seriously, the first level of QA should be the developer. Before it leaves the developer, the code should work reasonably well or at leave pass some sanity checks. Not, "it compiles and links, so I'm done."
Developer gods (Score:2)
Re: (Score:2)
"that harsh of a standard" and
"Every character must be right."
Maybe I've been working too much this weekend, and drinking the whole time. Who knows?
Yes/No. (Score:2)
Developers should be required to QA all their own code, but there still needs to be a second QA pass done by someone who did not write it. Basic human psychology causes natural blind spots in one's own logical thought processes. It's impossible to be completely unbiased about stuff you wrote yourself. So, while a developer is the best person to QA their own work, they're also usually inherently incapable of completing the task with reasonable accuracy in a reasonable time frame. Therefore, 2 people at m
Depends... (Score:2)
Re: (Score:2)
If you run a shop without continuous integration/deployment, full testing automation, A/B deployment, constant feedback loops,
Then you're not doing web development. Seriously, 'Software development" is not a different way of saying "Doing web-dev".
Developers testing? (Score:2, Insightful)
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 gr
aka (Score:2)
money quote (Score:2)
"If our site is down now, people will generally come back later," Brennan adds
In other words: we've conditioned our users to accept being shat upon.
Oh sweet holy hell NO. (Score:4, Informative)
I've been a software engineer, a QA engineer, traditional IT SysAdmin, and have now found my niche in SysOps/DevOps/SRE/whatever-we're-calling-it-this-week. And good lords of Kobol, QA is absolutely necessary. The usual reasons definitely apply. A separate pair of eyes will find things you've been blind to because you're too close to your own work. Building things and breaking things are different skillsets and different mindsets. There will be edge cases that even the spec didn't anticipate. Blah blah blah.
But try being on the operations front line some time, and you'll REALLY appreciate a good QA team. Right now, I'm responsible for multiple products from teams that, due to acquisitions and re-orgs and different companies doing things differently, some have dedicated QA and some let the developers test their own code. I see the errors and failures before anyone else. And the QA'd stuff invariably causes me less grief than the "we trust the developers" stuff. Hell, if I had my way, we'd have QA vet ops changes and updates too; because I'm under no illusions of infallibility myself.
Developers are too deep into the code (Score:4, Insightful)
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.
QA can be a political friend (Score:4, Informative)
Lastly, a good QA will look to see that what was produced is what was actually asked for and promised. This is no small thing, because many programming teams can lose sight of what the contract actually says. "But it's better" is something that should be negotiated, not just delivered.
But that said, QA can be a major road block. It is not uncommon that you throw things over the fence only to find that QA has hyper focused on something that isn't a requirement. For instance you might have some system that does echo location to find the distance to a wall. Your requirements call for one successful echo location every 10 seconds. You fire out 10 per second and around 50% fail. The reality is that you are getting roughly 5 ranges per second and never will you miss your target of one every 10 seconds. Yet QA gets all wound up about the 50% failure rate and reports that the product has a 50% failure rate. This is where you begin convincing the accountants that the QA department needs a head count reduction.
Oh...we almost forgot (Score:3)
It's cheaper. Did we mention that? It's 'way cheaper.
Re: (Score:2)
Good question. One they've answered to their own satisfaction, I guess.
independent review (Score:4, Informative)
Bad Idea (Score:2)
The problem with this is that the programmer knows too much about the code. If there is a form involved, the developer knows what goes where, and if the field name is nonsense, he will still enter the right thing. If the field says 'Name', and the average joe enters his name here, and the developer wants the guys Userid... The developer won't catch this... the Q/A guy will enter hist name, not his userid, and the test will fail. There are tons of examples where the look and feel is wrong, or the error
Good thing this is from a fashion retailer ... (Score:3)
For the trivial, maybe (Score:4, Informative)
Should Developers Do All Their Own QA?
If you can do that without deleterious consequences, then your work is trivial and/or not overtly complex.
Otherwise, such a thing is insane, specially if you work in developing actual products (shrink-wrapped software or software bundled in hardware), or complex services. ) And let us not even mention software related to avionics, weapons or medical devices (where QA is done by a separate organization to remove bias.)
The primary concern is always bias, bias that come from first-hand knowledge of a thing (or assumptions about a thing.)
It is a lot easier and effective to have a 3rd party dedicated to methodical black box and end-to-end integration/UA testing than to get a developer to test his own creation to the breaking point.
There is a reason why organization hire external teams to perform penetration testing of their infrastructure. He who knows nothing of the internals a-priori is the perfect person to black-box test the shit out of something with nothing but specs.
QA is a cost center (Score:2)
QA is a cost center, management is always looking to cut or make more efficent cost centers (and at the same time maximize profit centers)
It's no wonder every manager under the sun thinks they're the genius who can "solve the QA problem" and return 1-6 people's worth of payroll to the bottom line for that big annual bonus. The problem is that while YES you can get away with no QA in a very high functioning development team, on certain products,
A) most teams are not high enough functioning, e
Most assumptions come back to bite you (Score:3)
This is really a lame-brain position. As a long time developer I have two mottos:
* If it isn't tested, it doesn't work.
* A developer make assumptions all the time.
I can guarantee that, if I was responsible for QA on my own code, things would be broken in subtle ways.
Many years ago I did QA consulting for AT&T. We set up a system where the human factors engineering group would document an application in a specification. One copy went to the developers and one copy went to the QA personnel. The QA staff designed a test plan from this spec and then implemented it against the product sent from the developers. I can't tell you how many things the developers missed because of assumptions they made that were caught by the test plans.
Always need another set of eyes (Score:2)
It depends (Score:2)
On who's going to do QA.
If she's a QA professional, then it's ok.
Otherwise do it yourself to save resources.
Software is a broad industry... (Score:2)
If you are standing up some trivial web application and call it your 'software project', then maybe you are overthinking it to have a lot of people in different roles. Of course if your web application is more involved or more severe, then you need testing from a separate perspective.
If you are writing some particularly custom software for a particular market, then you should probably have a pool of testers that may not know how to program, but they are probably more in tune with your target userbase. I o
Developers should QA, but not be the only QA (Score:2)
This quote says it all... (Score:2)
"If our site is down now, people will generally come back later,"
They don't care about quality and how it affects their customers. They think their customers have all sorts of extra time to do double work because of software errors. I have to wonder if they company takes the same lackadaisical approach to the quality of their products? ~It's OK if our products are bad, because the customers will just buy another...~
Here is a certification program for your new plan (Score:2)
This is the quality of QA you get when you have your dev team do all the testing.
https://blog.codinghorror.com/... [codinghorror.com]
Pay difference (Score:2)
You pay QA people less than you pay devs and it's a different skillset.
So this guy is wasting money and getting a worse product. So win/win.
No, they should not (Score:2)
A developer testing their own code outside developing and maintaining automated tests is
Not one mention of DevOps? (Score:2)
(OK, I found one occurrence.) But seriously, this is what's being sold in management consulting "corporate DevOps transformation" packages. The first rule is almost always, "Go fire your QA department and make your developers write automated tests." This is exactly what the executives paying the management consulting firm for their "digital transformation strategy" want to hear, and that's magnified by a bunch of Google "visionaries" touting the same. Not every business is Google, and IMO DevOps works only
Well this should go well... (Score:2)
" the company has now moved all of its QA workers into engineering roles."
So inexperience engineers are going to be releasing code with no QA.
You can't make this stuff up.
Re: (Score:2)
The most productive team I've ever worked in had a simple policy.
1. You wrote your code.
2. You documented the developer's to your left's code.
3. You tested the developer to your right's code.
Harsh, but it worked really well.
But the developer to my left is an analog circuit designer and the developer to my right is a design automation expert. I do cryptography in the middle. I don't see this working out.
Re: (Score:2)
Where I work, developers get paid a lot more than QA, so it would be silly to use developers as QA. Also, it is a different skillset. A good car mechanic isn't always a good driver.
Re: (Score:2)
In my experience, QA may get paid less, but they work harder than the developers.
Re: (Score:3)
In my experience, QA may get paid less, but they work harder than the developers.
In my experience, Bricklayers may get paid less, but they work harder than the QA.
IOW, you don't have a point. We don't pay people more for working harder. We pay them for the value they bring.
The more high-quality devs you have, the lower the value of the QA as there's fewer issues to be found and reported.
A place with shitty copy-paste devs needs better QA to stop unsuitable product from leaving the company, so the QA there is more valuable.
Peer review is great. It's not QA. Users are stupi (Score:3)
Peer review is great. I introduced it at my company. It's not QA.
Users do stupid shit, shit no programmer in their right mind would ever think of doing. As an extremely simplistic example, at my job we have a script that calls nap with various arguments, including a list of IPs provided by user. The programmer tested it with some IPs. The peer could test it with some other IPs. The programmers made sure it works. Users will pass it 0.0.0.0/0, and fa70:638:363:7363::76. QA does the same, because QA is
Re: (Score:3)
When does Bob start writing horrible code, knowing that Margareth will find the bugs and clean it up for him? And when does Bob get the promotion because his code shipped faster, and Margareth's slower developed code fails to be presented early? So Bob gets to go to luch with the boss, go tot the company picnics, and gets invited to design review meetings because "they ship faster"?
I've seen this happen. It's been done to me, as "Margareth" in the story. I eventually had to talk with my manager, from quite
Re:Sure! (Score:4, Insightful)
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.
Re: (Score:2)