If the team culture is the problem then fixing the team culture is the solution. If it feels appropriate go to your line manager and ask for help. Its a management role, as far as I’m concerned, to see that the teams work well together.
The people who put you in the “bad guy” role have their reasons. These reasons fall into two general categories: hard to fix and less hard to fix.
Hard to fix reasons are things like inculcated prejudice. People who, for whatever reason, don’t like you or your role and refuse to see otherwise under any circumstances. These people are horrible to work with, and finding common ground can be really hard work. If a company hires many of these people it can cause a company to collapse under its own misery and refusal of teamwork. Then you get siloed waterfall. People are generally insecure. This can cause some people to blame and others to bond.
Less hard to fix reasons are things like misunderstanding of testing. People who don’t know what you do and assume you’re there to gatekeep the project and point out their mistakes.
First thing to do is put yourself in the position of offering a service with your testing. Your team are (some of) your clients, and you’re there to provide them with the help they need, catching those rogue problems before the customers see them, guiding them with helpful insights to make their job easier and take away their stress. One approach is to ask them individually (or as a group, if you have that sort of team) what the problem is. Something like “I feel that something’s wrong with the way we do things. Is there something I can do to make things better? Is there anything I do that annoys you?”. The rule is: never, ever blame anyone. Blame yourself, blame the process, blame the context, blame the alignment of the stars, but if you blame a teammate you have an adversary no matter how right you are.
This isn’t so that you then go and do everything they say, it’s so that you can see why they feel that way. I sometimes find this question gives the answer “no, nothing, everything’s fine” which could be an indication that you’ve misread the situation (I’ve done this before, and talking it out proved to me that I just felt targeted but actually everyone was fine with the way we work and it was me that was my problem). Sometimes this requires a “so why do we fight over bugs?” type follow-up question to get the full story.
When you know why they feel that way you can offer to do something differently (if you feel it’s appropriate), offer an explanation of why your role is supportive and negotiate your way to a better working relationship, etc.
Sometimes it’s the process’ fault and because you’re the end of a process you get labelled the bad guy. You could offer the process as a “to improve” and question how you might do things better. Maybe getting the product earlier, pair testing, being involved with design up front, etc could help reduce your bugs. Maybe clearer, shorted bug reports might help. People over process.
Also make sure you’re not doing something that you don’t need to do: gatekeeping quality, holding up builds, deliberately (or accidentally) wasting the team’s time, raising bugs nobody will fix, raising bugs people cannot read or in a way that they can’t understand (ask them what they want in a bug report), insisting that bugs be fixed rather than offering compelling reasons why then leaving the decision to others, that sort of thing.
Sometimes we are sacrificed on the altar of process, sometimes we genuinely are doing something wrong. If you go in with humility, and suppress your hulk rage (should you have any), and offer an improvement to the service you provide through education or process change, that’s how I generally get things to improve. Or I move companies.
To summarise:
- You need to have an accurate picture of the situation. Maybe you’re the bad guy or maybe not. The only way to know for sure what’s wrong is to ask. It’s for everyone’s benefit that you work as a team.
- You need to offer a service to your clients that they are happy with.
- You need to be seen to be offering a service to your clients that they are happy with.
- If they are unhappy with the process by being unhappy with you: make the process the focus of the team and band together over a common enemy… and change the process.
- You need to be seen as competent, but in my experience being seen as empathetic and supportive is even better.
- You need to write bug reports that your team can make easy use of. If they struggle with your bug reports then your bug reports are bad. Ask them what they want.
- When you give your team what they want you’re more likely to get what you want (egs. coding testability into the product, test tools, patience)
I hope that’s helpful. Without specifics it’s really hard to fix something like this because it’s full of possibilities. Hopefully I’ve provided some inspiration for some approaches that might bring you closer to a fix to the problem. When that’s fixed you’ll very likely feel much better, because you’ll feel that you’re doing work that’s seen to be valuable.
