Testers and Developers Think Differently

Software development requires various talents and roles. This article takes a look at two of these roles: testers and developers. On an effective team, testers and developers complement one another, each providing perspectives and skills that the other may lack. A common mistake is to see testers as junior developers, and to thus encourage them to emulate the skills and attitudes of the developers. In fact, good testers have many traits that directly contrast with the traits good developers need. With understanding, managers can make the most of these divergent skill sets and use them to build a successful team.

Many developers don't realize how difficult system testing can be. It takes patience and flexibility. It requires an eye for detail and an understanding of the big picture. Many testers are frustrated working with developers who think testing is easy. My understanding of this dynamic was deepened when I got a chance to see several developers take over the system testing. They had been used to relying on a team of dedicated testers, who were no longer available to test the product.

Since I had experience testing the product, I trained them during this project and saw them struggle with tasks they had previously underestimated. In the process, I noticed some differences between the skills and attitudes of testers and developers.

I want to avoid stereotyping. There are, of course, many good developers who can test well, and there are many testers who can write decent code. But in many ways, the skills that the jobs require are different and often in opposition to each other. Understanding this is important to getting teams of different people to work well together.

Embracing "Dilettantism"
A dilettante is someone who dabbles in a practice or study without gaining mastery. The term is often used to disparage a lack of commitment or seriousness, but good testers are able to make judgements even when they may not have mastered the specific subject at hand. Their strength is often their ability to be generalists; they need to have a broad understanding of many areas. This contrasts with developers, who are often required to be specialists in particular technical areas (networking protocols, for example, or database internals or display libraries). Testers, in contrast, need to be able to get up to speed quickly on any product that they test. They often have little time to learn a new product or feature.

On the other hand, developers need to have a thorough understanding of the libraries or protocols they'll be using before they can work on something new. Otherwise, they may break something. They're used to being allowed to gain mastery before being expected to deliver. On my project, I saw developers who were used to this kind of arrangement really struggle when they had to test dozens of features that were new to them in a short period of time.

Testers need to have the kind of knowledge that users have. This helps them use the product the way a user would, instead of the way the developer might like them to. Thus it can be important for them to not be familiar with the internal architecture of the product or perhaps even to act as though they don't know it when testing. The tester has to value a certain kind of ignorance or naivete. Developers, of course, can't afford this kind of ignorance. Developers may see this kind of ignorance as a sign that a tester isn't smart enough or is even being difficult. I had great difficulty getting developers to test from a user's perspective