Microclimate Within the Team: Developer – Scrum Master – QA Tester

One creates, and the other one breaks. One tries to build anything perfectly from the first time, and the other tries to destroy it into dust. One is an optimist and another is a pessimist. It seems to be impossible to bring these people together.

“So what?” — you may ask, — “Who needs such polar opposite people to become friends?” But what if these people work in a single team? What if you are that pessimistic QA developer who likes to obliterate everything? Or even worse – you’re a scrum master on a team which operates in “cold war” mode? And the tense atmosphere in the team adversely affects the quality of the product and the speed of work on it.

This article lists the most common cases where the relationship between the developer and the QA tester is so heated that they could even melt metal. It also describes tips from personal experience (QA tester and scrum master)  to improve these relations.

Find below an article-play in four acts. Choose your role, depending on your position in a project.

Main roles:

QA tester — the person who has recently started to work in IT or has recently been transferred to a new project where there’s not much to be familiar with someone (yet).

Developer (best friend of QA in future) — the person who has worked for N-years on the project, has eaten N-kilos of salt and made testers who worked with him eat the same amount.

Scrum Master — the person with proven experience in QA testing. He’s managed to work with different types of developers (juniors and old-timers), since then he does not like to salt food (at all). Recently he was transferred to the position of scrum master.

Act 1. “Bug or Feature”

One of the most common conflict flashpoints between developers and testers is the difference in views on the end results. Almost every QA tester has faced this situation.

So, imagine just such conversation in the hallway. The developer is running somewhere in a hurry.

QA Tester: “Hi, wait a second! You have a defect (satisfied smile). When you click the “Back” button, the entered search values are not saved.”

Developer: “Why do you think it must be saved?”

Tester: “This is intuitively understandable. You went back a step and should see the entered values.”

Developer: “This is not a bug, but in fact a feature. I don’t have time for explanations!”

The developer  rides smugly off into the sunset, pumping his fists in the air to the ghostbusters theme song. The Tester stays in the hallway with an unpleasant feeling of unfinished talk and question what to do next: agree or catch him to argue.

Tip 1

The first mistake is the wrong place for a talk. Even if you have the desire to attack a developer in the hallway and flood him with inquiries, you better find another place. It’s much easier for developers to take criticism (and the defect found is a criticism for him) in his workplace.

The second one is submission of information. Yes, the tester has found a bug. Yes, he gets his salary for a good reason. However, he should control his non-verbal gestures. A Cheshire Cat’s smile won’t allow one to establish working relations with the developer.

Also personal attacks and usage of phrases like “YOU have a bug”, “YOU made a mistake”, “YOU coded such a strange thing here” won’t work. Remember, a measure defect is a holiday for a QA tester, but a mourning for developer.

When the situation from the category of “Bug or feature” appears and communication between developer and tester leads to nothing, then the scene appears (well, should appear) the scrum master (SM).

To set up a meeting between developer/tester/product owner and resolve the situation, thereby eliminating the scandalous scandal inside the team – the sacred duty of SM. Delaying a meeting is not worth it, but it is not necessary to arrange each incomprehensible question. Otherwise, the team will hover over the tasks for too long.

Act 2. “Cannot reproduce”

Many testers have fallen into despair when heard developers answer “Cannot reproduce” on bug committing.

So the usual talk during daily grooming meeting.

Developer: “Bug DE12345 can not reproduce. Again. Now I’m definitely closing it with the status “Can not reproduce”.”

Tester: “No, you can’t! Everything is reproduced, I’m sure of it!”

Developer: “You’re probably the only one who can reproduce it. So this is a permissible loss. Or, possibly, you wrote down fuzzy steps.”

Tester: “My steps can not be fuzzy!”

Tip 2

The thing is, the tester was super sensitive about criticism. Each tester likes to report on bugs to developer, but not everyone knows how to hear criticism. This format of communication will not allow them work fruitfully together. The reaction to criticism should be calm on both sides, if you do not agree with something – just try to understand constructively.

There may be many reasons why the tester sees bug reproducing, and not all of them are obvious. Searching for them can take time, and it is better not to throw a bug. Remember, so-called “floating bugs” can also be found by a customer.

After the first return from developer, add more specifics to the steps of the bug: the exact version of program, the browser version, pre-setup (if needed), etc. Any little thing, even the most obvious in your opinion, can be a reason for reproducing the bug.

If it didn’t help, then try together with the developer to reproduce on his system or on a third party system (here again  SM can be useful). Joint labor unites.

Act 3. “Overvaluation of the bug”

Each bug found by a tester (especially junior), seems indispensable to him. Seems that if it wasn’t found then the release would have never happen.

So, the conversation in the team chat:

Developer: “Who and why has put a critical severity to bug DE12345???”

Tester: “It’s me. Well, the defect is so critical…”

The developer: “No. No. No. There are 3 workarounds ! You referred DE67890 to the critical too?”

Tester: “Well, there’s a general abyss in security”

Developer: “This is not a valid scenario! If you do not understand the value of critical severity, then you shouldn’t use it! I spent half a day trying to reproduce 2 bugs, which are at midcritical severity level!”

Tip 3:

In this case, the developer’s reaction (although it’s not entirely calm) is understandable. All critical bugs must be fixed first, because they can block not only you, but also a set of teams.

It is not advisable to put the critical severity on all bugs, because a tester risks becoming, “a boy who cried wolf.”

But putting down all the bugs underestimated statuses is also dangerous, because it can lead to the same thing.

In order to avoid this, it is necessary to clearly understand the statuses of severity, which of them should be put. An explanation (or a reminder) of each of them can be assumed by the scrum master (if QA techlead is busy).

Act 4 “Bug found in the assembly”

Obviously, it is a nightmare of any tester, regardless of his experience, job seniority, status.

If the bug was found in the explorer phase, then the developer is considered to be guilty. If it was found in the production phase, then it’s considered to be the tester’s fault in 98%.

And it is fact, just accept it as a reality.

And here, unlike in Act 1, the developer and the tester change roles. And if the relationship between them is not very friendly, then the following dialogue is possible:

Developer: “Well, now you have a defect (a satisfied smirk)”

Tester: “Yes, probably (he quietly bows his head)”

Developer: “Did you even test this functionality?”

Tester: “I did”

Developer: “How did you manage to miss this defect???”

Tester: “… “

Tip 4:

In this case, the tester can finally understand the developer’s feelings when they find a bug in his code. Now he understands exactly how to do it, and most importantly, how not to, present the news about bug.

At first we said that it’s the fault of the tester in 98% of cases, in the remaining 2% there is all sorts of third-party reasons (merge between developers, an area that is usually covered by an autoteam, poorly described documentation, etc.).

To focus on 98% or 2%, this is the main difference between a friendly team and the team in which the “cold war” is taking place.

Anyway, to find the cause of the bug is super important in order to avoid such an incident in the future.

Tester shouldn’t deny his guilt and shout about his unbelonging to this bug. Awareness of the importance of the error, in this case, demonstrates his seriousness and attitude to the product as a whole, and do not forget that admission of guilt is always a mitigating circumstance.

It is important for scrum master to strike a happy balance when talking to the tester. It is clear that the SM does not need to yell at him, but he can’t just allow the situation to fade away. It is important to make sure that he is aware of his mistake and will be able to prevent this situation from now on. This kind of conversation should not be spent in front the team, a short talk tet-a-tet will be much more productive.

The case when the bug happened due to the fault of the 2%, is better to discuss with the team. Nothing brings a team together better than  a discussion of other people’s mistakes :)

It is important to remember that the task of team building refers more to the scrum master. To help the team to establish friendly relations is included in the list of direct duties of the SM, along with a set of meetings and retrospectives. The logic is simple: the more friendly the atmosphere on the team is, the more effectively it works (it is checked on personal experience). A good Scrum Master in the team is a friend, helper and peacemaker (if necessary).

There are a lot of ways to rally the team and many articles / books on this topic, but the main thing to remember is that all the teams are specific and there is no universal way to do it. Everyone will be able to pick their own, by trial and error.

Beautiful speeches, such as “We are a team, we must, and therefore we can…” — do not always fit all the timelines and do not always lead to the expected result. A good alternative may be to sit around in a bar or organize an evening of board games with juice and pizza, remembering the bright moments of the project during the evening. The main thing is to focus more on achieving the goals of the team in general, rather than one individual teammate. Show that you are cool and friendly TEAM.

The curtain falls.