Tester vs. Developer - part 1

A lot has been said about testers and programmers having different ways of thinking. It is quite obvious that testers look at the product from a different perspective than programmers. Often it is much easier to detect a mistake in the work of someone else than to see it in your own. That is why we need more or less independent testing.

There is yet another difference, a difference in working styles. The tester’s work usually involves frequent switching of attention: during a day the tester may sometimes perform dozens of unrelated tasks. Programmers work the other way around: they typically work “in a flow.” This peculiarity of the programmer’s work has been described by Tom Demarco and Timothy Lister in their marvelous book Peopleware: Productive Projects and Teams: “Flow is a condition of deep, nearly meditative involvement. In this state, there is a gentle sense of euphoria, and one is largely unaware of the passage of time: "I began to work. I looked up, and three hours had passed." There is no consciousness of effort; the work just seems to, well, flow.” It is this kind of mental state that the programmer needs to write high quality code.

You can’t switch to that state at will; it takes at least 15 minutes of immersion and concentration to get into it. But it is very easy to pull the programmer from that state. If someone pulls you constantly, you won’t be able to easily get back into that state again… The result is a lower productivity and increasing irritation at people who are bothering you.

You should account for that when communicating with programmers. Wherever possible, try to choose the most unobtrusive way to communicate with them. Thus, email is better than chat, chat is better than a phone call or sudden appearance. Some people are annoyed and distracted even by chat messages as they think that they are expected to reply immediately.

I do not call on you to refuse any form of live communication with colleagues, but just urge you to plan it in advance.

If you work in the same room with programmers, remember that the noise could hamper concentration and immersion into the flow. Keeping quiet, however, means showing respect to all your colleagues, not only the programmers. In a company I worked for there was a rule that anyone who wanted to talk by phone should go out into the corridor. I believe this is a very good rule for any IT company.

Constructive criticism

Frankly speaking, no one really likes being criticized. All people are different; some are more sensitive to criticism than others, but nobody likes it. Feeling oneself irritated, upset, or distressed when others point to your mistakes is quite normal and natural. The tester’s job, however, is to look for defects and problems, and to report them. In fact, all project members understand that, at least theoretically, but they still cannot get rid of this mindset…

Sometimes, an absolutely useless and even harmful antagonism may arise between testers and programmers, which destroys the team spirit, spoils the relationship between people, and creates conflicts. Ideally, all project members must keep in mind that they have a common goal, they are not enemies or opponents but colleagues, and that ultimately they all are in the same boat. Nevertheless, it is not always the case in practice.

A lot has been said about constructive criticism, but not all advice is applicable to our work. No, I am not going to suggest you writing bug reports by using the famous sandwich feedback technique (praise in the beginning and at the end of a critical comment). You cannot even cheat a five-year-old child with this trick more than once or twice. Generally, the very form of bug report protects us from non-constructive criticism; so when describing defects you should remember only one principle: constructive criticism must be well substantiated. Explain why you think something to be a defect. Ideally, give a reference to the specifications or standards which the program must comply with. If you find it difficult to explain why this is a bug, it means something is wrong there. If you just think that “it would be better the other way around”, maybe your comment should be considered as an improvement or feature request.

It is not too hard to make your bug report objective and constructive. It is much more difficult to communicate live. From time to time you need to discuss something in person, and that could be useful. Often, 5-10 minutes of live talk may be more productive than weeks of email exchange. The crucial thing here is to establish a constructive dialogue.

So, in our context you should apply the following principles of constructive criticism:

Choose time and place. You should not attack programmers with questions like “When are you going to fix bug AB-123?!” in the corridor or when they are drinking coffee in the kitchen. People accept criticism more adequately where and when they expect to hear it. It’s a good idea to schedule regular meetings with testing and development teams.

Avoid being too personal. Of course, your criticism should be aimed at the situation, not at the person you are talking to, otherwise they will get defensive and a constructive dialogue would be impossible.

Control your nonverbal behavior. It could be difficult sometimes, especially for emotionally charged people, the more so if they take their work very much to heart and are really concerned about the product and project. It is worth some effort, however, to control yourself. The volume of your voice, gestures, intonations – all these are as much important as the meaning of your words. Even if you use neutral phrases, but non-verbally express your negative emotions, this may hurt your colleagues’ feelings, and they might react negatively and emotionally as well, without perceiving the exact meaning of your words.

Focus on the most important things. Choose the main points to which you want to draw attention and talk on these points, leaving the low-priority issues aside. If you pour too much information on the listeners, they will not remember everything, or not exactly what you think the most important.

Always give your colleague a chance to answer. Listen to objections and explanations. Even if you disagree, give the other party a chance to speak out.

Show that you are open to criticism too. This is a psychologically important thing – to show that it’s not a one-way process and that you are ready to accept criticism of your work. You may suggest developers to take part in the peer review of your test documentation (test cases, test plan, etc.). If they agree and find some time for that, it would be quite useful, and not only from the psychological point of view, as they might have really good ideas how to improve the testing process. If not, you gave them a chance at least.

Remember you are one team. Trivial as it may seem, but you should keep that in mind and occasionally remind the others of that if you see that your critical remarks are unwelcome.

And another thing that is important if you share a common space with programmers. When you find a cool bug, your enjoyment is quite understandable (to other testers), but try not to show it off too much – people might misunderstand you and think you indulge in malicious joy.

In our next article we will look at how we can improve the technical feedback between tester and programmer.

Victoria Slinyavchuk
Consultant on Software Testing