News Flash: Developers Love Testing…Almost As Much As Doing Taxes
Is there anything worse than doing your taxes? Apparently, for most software developers the answer is ‘yes’… testing software. And this issue is costing companies…often to the tune of hundreds of thousands of dollars for some of the more severe bugs.
Most tech execs and CTO types will tell you that having your developers test their own code — and not investing in proper testing resources — is a recipe for disaster. And yet inexplicably, some companies still go down this path.
We’ve all heard the numerous arguments before: developers are too valuable to spend their time testing (eg: an engineer in Boston comes fully loaded at $120k); developers make lousy testers; these two separate functions should each be left to the experts.
Well Chris Matyszczyk from CNET (@ChrisMatyszczyk) says that, in addition to those arguments, there’s another reason to invest in proper testing: most developers would rather do their taxes than test code. And he’s got the stats to back it up:
Developers seem to be increasingly bugged by the agony of ill-tested software. All but 11 percent of the respondents cited either design defects, problems in test execution, or simply insufficient time spent on testing on all platforms and targets. And 58 percent named the latter two as the greatest evils.
More than half declared that the last significant software bug cost their companies an average of $250,000. So now, even I, a regressive in so many ways, see just how painful developers’ lives really are.
However, this research doesn’t seem to account for all the depths and nuances of pain. It gave respondents the option of choosing only the dentist, the fender-bender, or the taxes when expressing their dissatisfaction on, say, discovering that management won’t be investing in proper software testing or that sorting out the bugs is down to the developer.
I’d love to hear from the testers and the developers out there. Should testers be responsible for their own QA? Should they own a small part of testing (eg: unit testing only)? Or should development and testing be separated and left to the specialists? What say you, oh wise ones?
The best situation is developers that do some testing (test driven development, unit testing) and testers that have at least a touch of development experience which in my mind makes you a better tester and better facilitates working with developers.
But one without the other is a shortcut. In the end shortcuts will end up costing you more than doing without. It will likely cost you more time in fixing bugs and will likely cost you some customers.
As a developer, I hate testing, but my code has gotten so much better with TDD that I promptly bought the domain
OTOH, exploratory testing is fun and reminds of of my hacker days 
I think that the genius ‘security researchers’ who find amazing vulnerabilities are really exploratory testers.
I don’t think that developers hate testing. When I was a developer, I understood the importance of testing my code before submitting it. IMO, developers do mean to test their code. However, the large number of problems ( I have written about some of these problems) that must be solved before producing working code in a tight schedule results in defects slipping away. Realistic schedules are key to allow developers to test their code thoroughly.
he best situation is developers that do some testing (test driven development, unit testing) and testers that have at least a touch of development experience which in my mind makes you a better tester and better facilitates working with developers.
The best situation is developers that do some testing (test driven development, unit testing) and testers that have at least a touch of development experience which in my mind makes you a better tester and better facilitates working with developers.
When I was a developer, I understood the importance of testing my code before submitting it. IMO, developers do mean to test their code. However, the large number of problems ( I have written about some of these problems) that must be solved before producing working code in a tight schedule results in defects slipping away. Realistic schedules are key to allow developers to test their code thoroughly.