Obviously, I realize that each and every QA specialist or application tester can point out multiple team conflict examples that may appear between them and the rest of their team. However, I decided to present you with the seven most common conflict outbreaks you’ll experience while working in software companies.

A team member is QA-sceptic

Nowadays, in the vast majority of software development projects, the role of the QA specialist is well known. You don’t have to encourage anyone to add the application tester to the development team.

However, it may happen that in the team you’ll have a person who will not be that familiar with the QA specialist responsibilities. Or, what’s worse, someone who thinks that the most important role of the QA specialist is to grumble. 

What are the signs of the upcoming argument? Developer vs tester

Let’s imagine the project’s kickoff. Everyone introduces themselves, talks about what they will do in a project, nice and easy – a real idyll. When it comes the time for QA specialist to talk… they’re torpedoed with some inappropriate questions. “What are you going to do actually?” or “Why are you even here? There’s nothing to be tested yet”. Sounds familiar?

It’s definitely the right time for the QA specialist to start their job. They can begin by explaining all the good practices for keeping high quality of the project to the rest of the team.

The tester should politely but firmly emphasize than even though there are no functionalities to be tested so far – it doesn’t mean that the person responsible for the quality is redundant. 

At this point, the QA specialist can take care of:

• preparing a clear decomposition of all the tasks,
• writing some testing cases, which may be used as a part of a project’s specification, 
• creating some end-to-end testing basics,
• preparing some BDD methodology basics,
• helping Product Owner create a project’s specification,
• identifying edge cases before any functionality is ready. 

From my experience I can say that there’s no better way to break the ice with the QA-sceptic developer than showing them the real value the QA specialist can bring to the project. It can be foreseeing some edge cases which may have been missed by the development team or finding some issues in “theoretically bulletproof’ solutions. 🙂 

QA specialist is the only team member with a “quality” in the job title

Does it mean that developers are not responsible for the quality in the project? Well, some QA-sceptic developers may assume that they’re released from the responsibility to take care of quality. They don’t have to complete documentation regularly or make sure that the status of the task is updated. In some extreme examples, they don’t even review their code before the test release. Why bother if they have the Quality Assurance Specialist in the team? 

Obviously, that’s not right and I presented a slightly exaggerated example. Nonetheless, I wouldn’t be surprised if the majority of the experienced QA specialists faced an attitude like this in their career. What to do in case of a situation like this? If you remain calm and talk to the QA-sceptic member of the team – it should help. You shouldn’t delude yourself that their attitude will change over the course of the project by itself. 

It’s definitely good to start with an honest conversation on a one-to-one basis. It’s because any feedback about personal attitudes should be provided that way. Obviously, the common responsibilities regarding the quality of the project is a good topic for a retrospective meeting too. In the atmosphere of openness and dialogue – you can remind the team members that taking care of quality assurance is one of the tester’s roles, but everyone involved in the project should remember about their responsibilities over the QA basics (like creating documentation). The project is co-created by the whole team. Everyone in the team has some unique experience which can help produce better documentation. That’s why everyone should work together for the greater good of the project.

Where’s my build?

Let’s assume that you managed to stave off a bad atmosphere in the team. Everyone knows what the QA specialist responsibilities are. Also, everybody in the Agile team is aware that creating specifications and taking care of quality is everyone’s responsibility. So what can go wrong?

Another challenge which the QA specialist may face is the lack of a stable version of the software to test.

Every application tester at least once in their career spent half of the day looking for a bug that appears and then… disappears. It may cause some doubts in your skills and… sanity.

And it often happens that once you’re reaching the verge of your mental strength, it appears that it’s “just” an error in an application build. It’s been updated all day but no-one told you. It’s not-that-good of a practice, obviously, but sometimes the whole team needs to work on that one testing environment.

However, it’s good to establish some rules about building new versions with your team. For example – it can be done only once a day, as the very first thing in the morning. It’s good to stress that developers should let you know before starting to develop a new build version. Maybe you can encourage them to automate this process and integrate the deployment with the project chat? It may improve communication between developers and the QA specialist. Also, a good practice is to add the information about the build number whilst reporting a bug.

Production deployment veto…

In other words – Project Manager wants to proceed with the deployment to production and the QA specialist says… NO. If I had to choose which conflict appears the most regularly, I would pick this one.

Honestly, if I get one dollar every time I disagree to proceed with deployment to production, I would have like 100$. I mean, maybe I wouldn’t be able to book a trip to Bali for that but you know – it’s still too much.

This kind of conflict is pretty tough. It’s difficult to say who is right. At the end of the day – you discuss with the Project Manager – the person who is responsible for the whole thing and has the final word in many cases.

It may happen that the PM decides that the signing-in functionality error is not a blocker and it’s okay just to inform a client about it as everything else works fine. You can imagine that the poor QA specialist has a terrible headache and is ready to do anything to block the deployment. 

On the other hand, there may be an application tester who will find a little button shift appearing on one device (with one of the older Android versions installed) as a blocker. How to avoid a situation like this? Ideally, you should have the acceptance criteria set beforehand. Also, it’s good to agree on a few scenarios of acceptance testing with the client.

Unfortunately, in practice you often lack the detailed requirements regarding what does and what doesn’t disqualify the new version from being deployed to production. In that case, you have to talk to the team and decide. You should consider what would be the best for the business, the security and the stability of the application. 

Obviously, I would be extremely dishonest if I said that all the team conflicts happen because of everyone but the QA specialist. I must admit that we – application testers/QA specialists can turn the cooperation into a nightmare too. What are the most popular QA sins?

QA specialist bothers the team instead of helping them

It’s probably the most typical scenario. Application tester who constantly reports all the minor bugs and notifies everyone using project chat. I believe that it can be really annoying as it may easily distract the team members and therefore – waste their time. You can imagine (or you may have experienced that even) how irritating it is to be distracted several times a day without a meaningful reason. There’s only one advice: never do that!

If any bug looks to be significant and needs to be discussed – it’s good to try and reproduce it first. At least twice… It’s pretty common that the development team analyses a bug which cannot be reproduced.

Another good practice is to check if the bug occurs in some different environments or on other devices. It’s also good to talk to someone who was responsible for this particular, affected functionality. If you couldn’t find any solution then you should schedule the meeting with the whole team to discuss the bug.

Procedures over flexibility

Another common conflict in the relationship between the tester and the developer is about rigid compliance with procedures of reporting bugs.

Obviously, there’s nothing wrong about procedures – those are extremely important and we all should follow them. However, there are some projects which need more flexibility or procedural adjustments. The worst thing to do is to persist on a certain procedure rather than trying to understand the developer’s perspective.

Sometimes a minor change in procedure – for example marking some elements on screenshots may be really helpful.

At times, it may be a bigger adjustment to the procedure, such as adding some more information about the device. It’s good to be opened for suggestions and flexible regarding some necessary adjustments. At the end of the day – procedures are to help us work more efficiently, right?

Developer vs. tester – who’s right? 

How many times have you heard any of the following? “This button should definitely be bigger”. “The user will appreciate this change”. “The client definitely needs a module like this”. And so on. 

Many QA specialists like creative solutions. That’s why, when testing an application, the QA often makes assumptions based on their own experience or ideas from the past. Obviously, drawing conclusions from previous projects is alright as you can foresee some potential bugs or traps in advance. But each project is different and it’s difficult to use your experience in all cases. What’s more – presenting your creative ideas may distract the team. Also, some solutions you may have in mind can be difficult to implement without major changes in the app itself. So how should you present the ideas to make sure you don’t disturb the team?

It’s good to define the goals and business environment at the very beginning of the project. At that point, it can help you determine what kind of app you would work on. Innovative product that should stick to the best UX practices? An app for elderly users that needs to be adjusted to their needs? You should consider everything before proposing any changes. Eventually, you build the app for the users – not for yourself. That’s why, it’s good to ask yourself some questions before presenting your ideas to the wider team.

• Do users really need this?
• Would that meet their expectations?
• What is the business benefit for the client?

Once you answer these questions – most probably you will be able to decide whether or not you should present your idea to the team and to the client. 🙂

Agile conflict resolution – summary

Working in any team means that at some point there may be a conflict. That’s okay, because sometimes an argument can help you verify your ideas. No matter what the source of the conflict is – you, as the QA specialist or any other team member – should take care of the healthy relationship within a development team. Remember that taking care of the quality of communication is an important part of the Quality Assurance. 🙂

Disclaimer: In the article, the terms “QA specialist” and “tester” are being used interchangeably. It’s intentional. However, the author solemnly declares to be fully aware of how diverse the QA specialist role can be and how far it goes beyond just application testing.