I’ve been trying to explain to a couple of Agile Teams why developers are usually not good testers; so after working hard to remember all the reasons I could think of (based on my experience so far) I decided to put together a short list and post it.
Don’t get me wrong I think developers should take part in the testing tasks, specially on Agile Teams, but I am also aware of their limitations and the cognitive blind-spots that tend to harm their testing; and as it has been said before, the first step to improve your weaknesses is to understand you have them.
Why developers (usually) suck at testing?
1. “Parental feelings” towards their code
Developers are emotionally linked to the stuff they write. It may sound silly but it is hard to be objective towards the stuff you create.
For example, I know my kids are not perfect and still I am sure I would have a hard time if someone would come to me and starts criticizing them in any way (after all they are perfect, right? :) ) .
2. Focus on the “Positive Paths”
Development work is based on taking positive scenarios and enabling them on the product. Most of their efforts are concentrated on how to make things work right, effectively, efficiently, etc. The mental switch required to move them from a positive/building mind-set to a negative/what-can-go-wrong mind-set is not trivial and very hard to achieve in a short time.
3. Work based on the principle of simplifying of complex scenarios
One of the basic things a tester does as part of his work is to look for complex scenarios (e.g. do multiple actions simultaneously, or make an operation over and over again, etc) in order to break the system and find the bugs. So we basically take a simple thing and look for ways in which we can complicate it.
On the other hand our developer counterparts are trained into taking a complex process or project and breaking it down into the smallest possible components that will allow them to create a solution (I still remember my shock in college the first time I understood that all a computer could do was work with AND, OR, NOT, NAND, NOR, XOR and XNOR operations on Zeros & Ones).
4. Inability to catch small things in big pictures
I can’t really explain the reason behind this one, but I have seen it many times in my testing lifetime.
One of the side-effects from becoming a good tester is to develop a sense to (almost unconsciously) detect what “doesn’t fit” in the picture. The best way to describe it is by the feeling one gets when something “doesn’t fit” in the picture but we just can’t put our hand on it; then by applying some systematic processes we are able to find the specific problem.
I had a developer once tell me that good testers can “smell bugs”, and maybe he was not very far from the truth.
5. Lack of end-to-end & real-user perspective
Do the nature of their tasks most developers concentrate on a single component or feature in their product, while they still maintain a vague idea of how their users work with their end-to-end system.
Testers need to have a much broader perspective of our products, we are required to understand and test them as a whole while using techniques that allow us to simulate the way users will eventually work in the real world.
6. Less experience with common bugs & application pitfalls
Again something that comes with time and experience is our knowledge of the common bugs and application pitfalls. Obviously as a developer accumulates KLOCs on his keyboard he will also get to meet many bugs and pitfalls, but as a tester we are going to gain this experience faster and in a more deeper sense.
An experienced tester sees a form and automatically starts thinking about the common bugs and failures he may find in it and starts testing for them.
My bottom line
It’s not they don’t want to do it, developers simply are not able to test in the same way we tester do. This doesn’t mean they cannot help in testing, and in some specific areas they will be able to do it even better than we do, but before they start it may help if they are able to map their testing-blind-spots in a way that will allow them to compensate for them.
Developer testing adds a lot of value to the general testing process… I am even thinking as I write this about a future post on the subject of the added value gained from pairing developers and testers.
Don’t get me wrong I think developers should take part in the testing tasks, specially on Agile Teams, but I am also aware of their limitations and the cognitive blind-spots that tend to harm their testing; and as it has been said before, the first step to improve your weaknesses is to understand you have them.
Why developers (usually) suck at testing?
1. “Parental feelings” towards their code
Developers are emotionally linked to the stuff they write. It may sound silly but it is hard to be objective towards the stuff you create.
For example, I know my kids are not perfect and still I am sure I would have a hard time if someone would come to me and starts criticizing them in any way (after all they are perfect, right? :) ) .
2. Focus on the “Positive Paths”
Development work is based on taking positive scenarios and enabling them on the product. Most of their efforts are concentrated on how to make things work right, effectively, efficiently, etc. The mental switch required to move them from a positive/building mind-set to a negative/what-can-go-wrong mind-set is not trivial and very hard to achieve in a short time.
3. Work based on the principle of simplifying of complex scenarios
One of the basic things a tester does as part of his work is to look for complex scenarios (e.g. do multiple actions simultaneously, or make an operation over and over again, etc) in order to break the system and find the bugs. So we basically take a simple thing and look for ways in which we can complicate it.
On the other hand our developer counterparts are trained into taking a complex process or project and breaking it down into the smallest possible components that will allow them to create a solution (I still remember my shock in college the first time I understood that all a computer could do was work with AND, OR, NOT, NAND, NOR, XOR and XNOR operations on Zeros & Ones).
4. Inability to catch small things in big pictures
I can’t really explain the reason behind this one, but I have seen it many times in my testing lifetime.
One of the side-effects from becoming a good tester is to develop a sense to (almost unconsciously) detect what “doesn’t fit” in the picture. The best way to describe it is by the feeling one gets when something “doesn’t fit” in the picture but we just can’t put our hand on it; then by applying some systematic processes we are able to find the specific problem.
I had a developer once tell me that good testers can “smell bugs”, and maybe he was not very far from the truth.
5. Lack of end-to-end & real-user perspective
Do the nature of their tasks most developers concentrate on a single component or feature in their product, while they still maintain a vague idea of how their users work with their end-to-end system.
Testers need to have a much broader perspective of our products, we are required to understand and test them as a whole while using techniques that allow us to simulate the way users will eventually work in the real world.
6. Less experience with common bugs & application pitfalls
Again something that comes with time and experience is our knowledge of the common bugs and application pitfalls. Obviously as a developer accumulates KLOCs on his keyboard he will also get to meet many bugs and pitfalls, but as a tester we are going to gain this experience faster and in a more deeper sense.
An experienced tester sees a form and automatically starts thinking about the common bugs and failures he may find in it and starts testing for them.
My bottom line
It’s not they don’t want to do it, developers simply are not able to test in the same way we tester do. This doesn’t mean they cannot help in testing, and in some specific areas they will be able to do it even better than we do, but before they start it may help if they are able to map their testing-blind-spots in a way that will allow them to compensate for them.
Developer testing adds a lot of value to the general testing process… I am even thinking as I write this about a future post on the subject of the added value gained from pairing developers and testers.
No comments:
Post a Comment