Looking into the mindset of a successful software team

1. Who is right?

The fact that testers and programmers have different mentalities is already clear, discussed, and known. It goes without saying that testers look at different products than programmers, and it's often easier to find the mistakes of someone else than personal mistakes.

Tester activity is usually associated with frequent changes of attention; sometimes over the course of a day, a tester can perform more than ten different tasks that are not too closely related.

1.1. Communication between programmers and testers

Programmers have everything different - they tend to work "in flux". What does this mean?! It means working in a deep and almost meditative immersion state. In this state, a person feels a slight sense of euphoria and does not notice the passage of time: "I started working. When I stopped, three hours had passed." The person does not make a conscious effort and the work seems to be effortless/easy for them. This kind of mental state is required for software development and writing high-quality code.

When it comes to communicating with programmers, perhaps the most effective method is discrete communication. So sending an email or writing a comment in a task is better than sending a chat message, and sending a chat message is better than interrupting in person.

Of course, direct communication should not be completely ignored, but it is better to plan it in advance so as not to interfere with the work of colleagues.

And if you share an office with programmers, remember that noise also interferes with their concentration and thinking. Of course, keeping a quiet work environment is a manifestation of respect for all colleagues, not just for programmers.

2. The Most Problematic Bugs

Often, misunderstandings and even conflicts between testers and programmers arise in connection with specific bugs. For example, this can happen when programmers reject a defect or when they express their dissatisfaction with the description of a defect. It is now the turn of the testers to adequately and constructively accept criticism. Consider the most common situations:

"Do not reproduce"

A tester must not tolerate when an error is rejected with such a resolution. This situation always requires additional procedures.
For you, this may be a signal that the problem is in the environment.

The developer might come to such a conclusion because they re-verified a different version of the product where some changes had been made. However, it's worth clarifying whether this is in fact what they did.

A better solution is to get a test execution tool that records all of your manual testing inputs as you work through a test.

It’s possible that you have not described the steps in sufficient detail or that you have forgotten about mentioning a prerequisite. Or it could be that the defect is not always reproduced, but you have not noticed this. This can be a frustrating situation to be in...

In general, it is important to have clear communication between testers and developers. The argument "but it works for me" is a very weak argument and cannot be used by a developer as a reason for not dealing with a bug. If the defect is reproduced steadily in the test version and in your test environment, you will have to insist that the developer pay attention to it. Add proofs such as screenshots and, above all, logs. In some difficult cases, extensive logging is needed.

"This is not a bug; this is a feature"

Perhaps every tester has been in the following situation: They think they have found a bug, but the developer does not agree with them, so they do not know how to proceed.
Perhaps you have not described the defect nor argued your case well enough. Think about what makes you think it is a bug. Return to your test base, read the requirements again and take a look at the trace matrix. Maybe, after doing this, you will find that you agree with the developer. If you still do not agree, try to support your case by finding additional arguments.

However, you might find yourself in a situation where the developer and the tester read the same documents but understood them differently. Who is correct and who is mistaken?  Maybe both people are wrong. It is worth discussing both arguments in order to try and reach a conclusion. If this is not possible, connect a third party - this could be a business analyst, a project manager, or another person who has the right experience and understands the project’s objectives?.​

3. Constructive Feedback

Let's be honest - no one likes criticism. People are different; some are more sensitive to it, some less, but certainly, no one loves it. Experiencing irritation, self-doubt, or embarrassment, when your mistakes are highlighted by a tester is completely natural. However, a tester’s role is to look for defects and problematic areas and report them. In principle, all participants in a project understand this, at least theoretically, but yet there is no way out of this particularity of the human psyche.

Sometimes there can be antagonism between testers and programmers, but this is harmful and completely unnecessary. This hostility can destroy team spirit, affect relationships between people, and create conflicts. Ideally, all participants in a project should remember that they are neither enemies nor adversaries, but rather they are colleagues in the same boat working towards a common goal.

3.1. Principles of good criticism

Focus on the essential elements. Highlight the main points you want to attract attention to, leaving aside insignificant trivia. If too much information is given, what is retained is not unparalleled and not necessarily what is the most important information.

Choose the right place and time. You should not attack programmers in the lobby or during a coffee break with the question: "When will you fix the ZY-123 bug ?!" People perceive criticism in a more appropriate way when they expect to hear it. Regular meetings scheduled with testing and development teams are a good idea.

Don’t lose the focus on the common goal. Each member of your team should evolve. They should start with accomplishing things they are told to do, in a way they were told to, and end up becoming a pro able to teach vs. just learning by self-developing and tuning their skills to extend their area of expertise. 

Always give the other person the opportunity to respond. Listen to objections and explanations. Even if you do not agree with the other party, give them a chance to talk.

Remember that you are part of a team. Of course, we all know this,  however, it is useful to keep this in mind and sometimes remind others about it when you or your colleagues are reacting negatively to criticism.

Another important thing to keep in mind if you are in a shared space with programmers is to be careful about how you react when finding a bug. Your joy might be easy to understand by other testers, but try not to make it too obvious as you might be completely misunderstood and associated with arrogance and insincerity.

Conclusion

The relationship between the tester and the programmer is just one of the aspects of a successful software team. For more tips on improving your team's performance, you can also check out our article on Integrating Quality Management System into Software Development Processes.