I consider myself a great tester among developers. I’m very strict about the way automated tests are written, including test names that are meaningful to the business or domain, not allowing tests to get tangled up in implementation details, etc. In my company I helped (along with a tester) introduce BDD techniques and acceptance testing using the Gherkin language, for the first time.

In other words, I care a lot about software testing, for a developer. I’ve spent a lot of time reading James Bach, Google Testing, Adam Goucher, Ben Simo, etc. – probably more than a lot of actual testers read. And I don’t mind telling you that my team (one among several) has consistently put out releases with the lowest bug counts and least serious bugs.

But I am not a tester. I would be horrified if the project manager came up to me one day and informed me that I was going to be taking over all testing duties. Here are just the most severe problems with that approach:

1. I don’t like testing. Most developers don’t like testing. And when people keep having to do something that they don’t want to do, they burn out. I commonly cite the lack of an actual QA team as one of the main reasons I left my previous company.

2. Exploratory testing (as opposed to writing the automated test code, which developers should be doing or at least reviewing) is a very manual activity. It’s inefficient simply on the grounds that programming at an experienced/expert level has a far greater ROI than testing on any level. We have a cross-functional team with a 2:3 tester:developer ratio and still the testers often can barely keep up because they have other duties (release management, regressions, etc.). It simply doesn’t make economic sense for developers to test.

3. Developers and testers have a completely different mind-set. It’s hard to explain unless/until you’ve had a chance to work alongside them. Good testers will attempt to do things that are not described anywhere in the spec, things that developers would never in a million years have thought to try, typically on the basis that it seems stupid to developers. But testers are testing for the user, not the developer, which means they need to intentionally try to do stupid things, to test everything as opposed to a well-known set of happy and sad paths. It’s very interesting to get a developer, tester, and BA/product manager in the same room and talk about a controversial bug; you’ll get a totally different perspective from each.

4. Developers know too much. Because they built (or helped to build) a particular feature, they know exactly what initial conditions are supposed to be in place in order to make it work, and will almost always take shortcuts in their testing such as directly modifying databases or temporarily changing configuration files. Even if they don’t do any of these things, they still know exactly what steps to take and in which order. Testers – or really, anyone who is not a developer – will lack this knowledge and/or the ability to take those shortcuts and must literally test the system from end to end, and the “integration” is precisely where the highest number of bugs usually tend to materialize.

The best way I can think of to summarize it in fewer words is:

• Developers are focused on the design
• Testers are focused on tasks
• Project managers are focused on features
• The rest of the business cares about the product

If you don’t have proper feedback from all of these different groups, your product quality and overall team effectiveness is going to suffer. Greatly.

Developers should not actually be responsible for testing. If you’re being asked to handle all the testing duties, run for the hills. It’s a full-time job that requires a very different skill set from programming.

P.S. If I had to guess why developers almost universally loathe testing, I would say that it is probably because it does not produce anything in the sense that coding does. Creating test scenarios is more of an analytical discipline than a truly creative one, and the creative sandbox is an important reason why developers like programming. It’s not coding that I like, per se; it’s seeing the fruits of my labours.

The end goal of a tester is to produce exactly what the developers don’t want to know about: a list of reasons why they have to stop working on that cool new feature and go back to fixing something that they thought was already done. It’s not a fun activity, for a developer.

I would say the problem is less that developers don’t like testing than that developers know the flow that they pictured the user taking through their product, so they’ll tend to unconsciously stay within that happy path. Testers, on the other hand, don’t know what steps the developer is expecting the user to take, so they’ll wander off the path and find out what breaks when you do that.

In addition, there are certain things you stop seeing or never looked at to begin with. For example, if I copied and pasted text that is shown on screen from a document that came directly from the client, I often don’t look at it for typos or grammatical errors.

What you get from a tester who is not a developer is a set of fresh eyes. Try as she might, a developer can’t look at her product the same as someone who has never seen it. So she may wind up running through it many times and not seeing as many things. This is not the best use of her time, since she will never be able to give you what a pair of fresh eyes would. Plus, she’s likely to be relatively expensive for that task.

If a developer has extensive knowledge in the company or in the field per se, then it may be possible for a developer to test efficiently.

One problem is that developers like to code, and you don’t code much in testing. Another problem is that the developer would likely be focusing on doing the task at hand (whether creating a new screen or fixing existing bugs) that he/she will not be able to test other parts of the code because the developer expects that since he/she did not change the logic of the other parts of the program, then the program should behave exactly as it used to. I’m guilty in both of those problems. 🙂

There are several aspects that make it difficult for a developer to be a tester. It is not an impossible task, but finding a developer who is proficient at being a tester too is not a common thing.

The developer is the advocate of the system is working right. Every thing that they have written and done prior is leading up to correctly working code. Every edge case has already been tested as part of writing the code. Every use case has already been coded. Every code path has been thought through. When the application is being delivered to a testing phase, the developer believes it is working correctly.

The tester is the advocate for the system is broken in strange and subtle ways – and they will figure out how. Sometimes this just involves the iteration of going through a number of testing scripts. Other times this is trying to abuse the system in ways the developer never thought of (what happens if I triple click here instead of double clicking? what happens if I enter the network broadcast address into the spot where I am supposed to enter the IP address of the router?). These are often things that exist just outside of the business specification.

Note the phrase above “abuse the system in ways the developer never thought of.” The developer of the code has a very difficult imagining new ways to break it that he or she hasn’t already coded for. This reduces the efficiency of the developer as a tester.

Testing is sometimes seen as boring to a developer. It isn’t seen as a creative process – there isn’t anything being built. This is often the mindset of the developer. Many developers get antsy and demotivated if they aren’t writing code for too long. Taking a developer and moving them from coding (where they could be writing the next round of features, or the next application) to a spot where all you are doing is running the same thing over and over is down right boring. And thus developers don’t often do it well.

A bug has been found and now the developer is back to code – finding the bug and fixing it. There is the switch from one mindset (testing) to another (developing) – Human Task Switches Considered Harmful. These switches don’t take place quickly. There are the practical sides of switching where you are physically working (you aren’t having the developer test the product on their own development work station that is customized far beyond what the product will be run on… right?).

All in all, while developers can be testers, developers are rarely efficient testers when compared to someone who wants to do testing and can maintain the mindset of the system is not working right.

Thanks for the quote from our book Automated Software Testing – a book we wrote 14 years ago.

Interestingly enough, from the responses here we can see that some developers agree they still don’t really like testing, because instead – from my experience – they like to focus on feature development.

Some do a really good job unit testing, but larger integration testing and/or systems of systems testing are not really part of their job description. Hence there is the need for a separate testing role that can focus on “other” testing from that of the developer/unit and component testing tasks.

Well it depends on what type of testing are you talking about. If you refer to unit testing or integration testing I believe it should be done only by developers since their code is going to heavily rely on it.

If manual testing or automatic testing for example I believe is a job for tester; developers will most likely not cover all the flows only the major one(s).

So in a work place, if a member from dev has to perform a testing
part, wouldn’t he’ll do it efficiently?

Obviously that is a bit of genralisation but yes, most often developers wont be effective testers. Testing is quite a hard skill, you have to get into the mind of the users also be able to effectively find all the ways in which the software can be used and abused. Lots of tests (ie load tests) require knowledge and licences to specialised tools.

And why developers don’t like testing?

Again a genralisation (some people do). The people that dont like it tend not to like it because its hard, they don’t know what they are doing and it takes time away from development.