How to Win Friends and Influence Developers

"Once more unto the breach, dear friends, once more; Or close the error with our Tester dead." With apologies to Shakespeare Henry V, Act 3, Scene 1

I have this view of a battlefield; where testers assail the bastions of the much beset developers. Unrealistic, you say? Aren't developers and testers at war? Are we not attacking the developers' code with our barrage of tests and expecting that they will admit our supremacy when their code is breached rendering their position (to our mind) indefensible?

Does this describe your project? Worse still, does it describe your personal attitude toward developers?

It should not be a battlefield we envisage, but an alliance; where testers and developers rely on the others' strengths to counter their weaknesses and thus achieve a common goal. Out of my research and experience I offer a few words on how testers can start to ally with developers - this involves changing how some of us view developers.

Developers are people. You may be thinking, duh?!? But some out there may believe that developers share certain characteristics with the machines they program; this should not be your view. Developers take pride in their work (consider the way a lot of developers hide "Easter eggs" in their programs containing developer "credits"), as do you? Tact is important here, as is appreciation. When developers achieve the "impossible", give them their due. When their "baby" throws up or worse, develops a deformity, choose your words with care, for it IS their baby. Do not be facetious, do not use irony, be direct and non-condemnatory. Get to know the developers as the people they are. This will help to build the alliance. Getting to know the developer and how he thinks can also give you new insight into your testing.

Next, remember that developers quite often believe that their work is adequately self-tested; as such they may resent the independent tester. Your role is that of bug advocate: bring your point across in a way that clarifies to every audience the justification behind it. You do not need to be forceful or domineering to be assertive. Bringing your point across by becoming forceful often causes people (developers) to dig their heels in and defend their viewpoint - even if it defies logic. Therefore, avoid being dogmatic on issues raised.
If you make this mistake developers may become negative towards you (I was once semi-seriously warded off with a crucifix).

As testers we are just as prone to believing that our work is adequate and does not need to be checked. Consequently, testers often show exactly the same resistance to having their work checked and criticised as do developers. A practical point in case, a dedicated tester I know wrote: 'after I had my very first "test pack" reviewed by the project team and received a barrage of suggested changes, I took it so to heart that I rewrote the document from scratch'.

Think, how would you feel if your work was under the microscope? The authors of Lessons Learned in Software Testing (Cem Kaner, James Bach, Bret Pettichord; Wiley, 2002) indicate that once you have developed "production code" and run the gamut of tester's, user's and other developers' criticism, condemnation and praise (probably in that order) you will have learnt how to understand and interact with developers. (Coincidentally, their book is a good reference.) I found that empathising with developers and their frustrations automatically builds a sense of tact into our behaviour.

Be constructive in your criticism. Yes, you are a critic; and much like any movie critic, you're a paid critic. But unlike many movie critics you are not paid for sharp, oft nasty, wit at the expense of the developer. Snide comments have no role in your job. Describe what you found, where you found it, when you found it, how you found it, how often you found it, how you repeated the find (and you'd better try, record-ably, to repeat it), why it is a problem (be specific, don't just say "it doesn't work") and what is your, arguably perceived, rating of the problem's severity. If you respect the developers' valuable time by giving them concise, accurate, yet descriptive bug reports, you will probably find that the developers will pay more attention to your work. Above all, avoid emotion, stick to the facts.

Also, on being a paid critic, you are not being paid to root out developers' bug creation rates, or to identify questionably dud developers to management. The current build is your focus, not its creators. You would be dismayed if your boss were to use defect metrics to gauge your performance, would you not? Likewise, avoid the temptation to use them against the developers. Your mandate is only to provide accurate, objective feedback on the quality of the build under test. You need to stick to your mandate if you are to win the trust and good-will of the developers. This mutual trust and respect will also propagate and migrate to the rest of the project team.

Developers are creative; they may not know one end of a brush from the other, but they can create code. They see a requirement and supply the code to make that requirement happen. As artists their interpretation of the requirement may differ from yours (or anyone else's for that matter), do your best to see it from their point of view before you jump in and tell them they've got it all wrong. Appreciate that lurking in them may be the inimical artist's temperament.

If you are involved from the start of the project, helping to clarify ambiguities in the requirements will typically make the project less the developers' impressions of the project and more what the client had in mind.
Developers are analytical; yes, one can be both creative and analytical at the same time. There is definite structure and thought behind the work they create. Boolean expressions have a certain elegance of beauty to them. And do you know when 47 equals 57? The hint would be, of course, that 47 is the equivalent of 2F which is the equivalent of 57 which is the equivalent of 101111. A developer would now definitely know the answer.^* Respect that developers have analysed the requirements and put a great deal of thought into their work. Respect the developers' intelligence. Respect their work. You will have to earn their respect through yours.

Developers are thoroughly grounded in the technology they are using. They know the development environment and technology inside out; this is part of their job. Testers are normally out of their depth here and should not try to tell the developer how he should do his job; lesson? don't try to figure out what caused a problem (unless, of course, you too are expert in the technology in use and it falls within your mandate), your job is simply to tell the developer what he needs to know to get his job done … do you see the difference? The first could get your bug report ignored, ridiculed and misdirect developer effort; the second has a good chance of getting the developer to improve the product, something you both want. A little bit of knowledge can do a lot of harm, or turn you into the unwitting court jester.

When you don't understand something, admit it and ask the developers for more insight - you'll gain more respect this way than by faking it. Testers generally do not have the time to become fluent in any one area of technology, and often, ignorance is not bliss but part of the service offering as the typical user is quite often similarly (or even more so) unspecialised.

Respect for the developer's technical skill and the willingness of the tester to learn from their expertise, can provide a cornerstone for a mutually beneficial relationship, providing a launching pad for a smooth testing effort. A willing and co-operative developer can provide many answers out of that "black box".

Developers see a detailed picture. Developers have a picture in their mind of how their part of the product should work, and, being human, they have probably made assumptions on how their module will interact with others. Bear this in mind when you are testing; if the environment permits, talk to the developers about their work, what they visualised, and ask if there are any working notes or diagrams that will help you to help them make the product better. If developers' assumptions on how their specific module should interact with other modules produces errors, report those errors as bugs with (dare I repeat) concise, accurate, yet descriptive bug reports.

Remember that developers want to make the product work, their unit tests focus on proving that it does. When you set out to find the ways and means to make it not work (which is within your mandate, after all) you will need to motivate why your bug should be investigated.

An example of one such bug:

In the days of National Service, an officer crashed a potential military system by doing something that the system's developers believed no-one using the system in practice would do. Part of the system required the operator to calculate three separate values from provided charts and enter these values into the relevant fields in the system. How did the officer crash the system? Simple. He did what he, cynical officer that he was, strongly believed any lazy Troep [slang for un-ranking soldier, in those days likely to be a conscript] not really wanting to be in the Armed Forces would do - he calculated one value and entered that value into each of the three fields. As the representative of the potential customer he had the right to demand that the developers cater for this, to their way of thinking, unlikely scenario.

You would probably not have the same force of persuasion behind your reasons for fixing "your" bug. You are generally a customer advocate, but not one whose opinion is as important as the customers. Kaner et al, in Lessons Learned in Software Testing, suggest that if you feel that the bug that you have uncovered is imperative to fix, find compelling reasons for the developers to pay attention to it. [There is a whole chapter in Lessons Learned in Software Testing on how to write bug reports that get noticed. Read the book if you are serious about testing, these gentlemen have plenty of experience in the field, and their lessons are compelling ones.]

Some thoughts on bug reports:

• Do a bit of research on your bug and similar bugs, to find out whether they are related and whether there might be a more serious underlying error.
• Find out from other stakeholders (e.g. the help desk, product specialists) what similar types of bugs have cost in time and money (do not tread on any toes).
• Find out if similar bugs in competitor products have been publicly reported by users.
• Find out if other stakeholders think the bug is serious (I repeat, do this without treading on any toes).
• Without inflating your report in any way, make your bug of interest to the developers.
• Write fact, not fiction.
• Describe how a typical user would experience the problem, and why it would bother them.
  
  An example from personal experience: the cursor of a certain version of an office suite I was using had the temerity to move, seemingly of its own accord, to another part of the document while I was typing. I don't touch type (a colleague once commented that for someone who only used two fingers I typed amazingly fast - I use a few more fingers now) so this used to drive me up the wall, it also caused me to upgrade … okay, so maybe for this reason alone the developer could say the flaw was "as designed", it helped to sell me the upgrade, but, it could have also driven me to the competition.
• Developers tend to despise tedium. So, if your bug is just one of a swarm, it is likely to get swatted; if it is an interesting specimen it is likely to be closely examined, even dissected.

Some thoughts on collaboration early in the project:

• Share with the developers the glossary of terms that the testing team have defined for the testing project if there is no project or company-specific glossary in use.
• Invite the developers to share their thoughts on the project, and also any preconceptions on testing that they might have - it will help you to know what you are up against, and also help to build the developer-tester alliance.
• Woo developers with the belief that testing will support them in their quest to provide a good product.
• Be a diplomat, first and foremost.

Accept that you will not always be liked by developers in the product team. An alliance need not be built on mutual liking, after all it is not a marriage, but on mutual respect. Make sure, however that there is no reason for team members to find you unprofessional, creative and/or a dramatist. Earn developer respect, if not liking, through your work and attitude, and an alliance will have been forged.

Natalie Stebbing

^* The answer: 57 is the octal value of the number 47₁₀ or 57₈; in the hint 2F is the hexadecimal value of 47 otherwise written as 2F₁₆ and 101111₂ is its binary value (1 x 2⁵ + 0 x 2⁴ + 1 x 2³ + 1 x 2² + 1 x 2¹ + 1 x 2⁰ = 32 + 8 + 4 + 2 + 1 = 47). 10₂ is the equivalent of 2₁₀ (i.e.1 x 2¹ + 0 x 2⁰). Get the general idea?

You might wonder why you would need the octal, hexadecimal or binary values of any "normal" (read decimal or base 10) number; well, you wouldn't, but developers would.

References:

Many thanks to Rob Kerrich-Walker and John Stebbing, my reviewers, for their invaluable input into this article.
Lessons Learned in Software Testing - A Context-Driven Approach; Cem Kaner, James Bach, Bret Pettichord; Wiley, 2002
Testers and Developers Think Differently: Understanding and utilising the diverse traits of key players on your team; by Bret Pettichord; January/February 2000.
Software Testing & Quality Engineering Magazine, www.stqemagazine.com

<< May / June 2004

September / October 2004 >>