Wouldn't it be great if everyone on your team loved testing and working with testers? When developers and testers have a respectful relationship, it's easier for developers to see the value and take an interest in testing. Instead, many testers pick up a knack of alienating themselves—and testing in general—from their team. The following is a list of ways in which testers may make themselves and testing irrelevant to others on their team, along with tips for avoiding getting stuck in these situations.

1. Insist that a highly functioning team working at a fast pace change their process just for you.
One thing I've noticed about good developers who work quickly is that if you find a bug, they often fix it before you even have time to write it up. If the developers have their own process for handling bugs and are effective at working through them, it's worth trying to do it their way before insisting that everyone changes to suit your personal needs. Otherwise, you slow down the pace and the developers will resent you because their work is taking longer for reasons that they cannot see.

2. Lock horns with the team on whether or not to release.
This can be hard for some testers to hear, but when to release really is not our decision. If you've advised the team of the risks they are taking with a release and everyone knows about it, you've done your job. It doesn't mean nobody listened to you. It means that they listened to you and decided to release anyway. It happens. If you keep disagreeing after the decision has been made, your team will hear nothing but tester interference.

3. After the business has made a decision you don't like, keep complaining about it.
One of the keys for having a fair discussion is that once a decision is made about something, it's time to move on. The truth is that there are plenty of changes and decisions over which testers have no control and no decision. It's important to be able to recognize what you can control and what you can't. That doesn't mean you can't report problems that result from decisions you dislike; just remember to keep it in perspective. If the problem is unlikely to be fixed, don't scream about it in your triage meeting.

4. Insist that everything be perfect when you look at it.
When the team is working on basic functionality for something critical like payments, it is not a good time to complain loudly about the rounded corners on the payment button. Doing so will only sidetrack the team from its central mission of producing a functioning payment workflow and sidetrack you from thinking about what may seriously go wrong, like if the system charges a customer $10,000 instead of $10. If the developers think you will sidetrack their work by only bringing up the minor problems instead of looking for big ones, you'll be seen as distracting from the mission. If the rounded corners really bother you, file it as a minor bug and bring it up later when the team is better able to focus on it.

5. Spread the attitude that developers are untrustworthy.
Developers make mistakes because they are human and because making software is hard. The ones I've known would never knowingly sabotage a project by creating bugs. Sometimes, they get the wrong information about how a feature is to be implemented or they don't get enough information and have to make some assumptions to finish their work. Treating them as though they intentionally did something wrong in the code to make your day harder is to blame them falsely and place them in a no-win situation. It's better to trust that developers are doing their best and not blame them for the bugs they produce.

6. Assume developers don't care about testing and testers.
Stereotyping developers as not caring about quality or not being interested in testing is to place unfair judgment on your teammates. I've met so many developers who want to write the best code they can. I've met developers who know as much and care as much about testing as I do. Highly functional developers are not stupid. Most have some humility about the code they write and want to make it better. If you work with such developers, you'll be working pretty hard to find their bugs. Spreading a false claim that they don't care about testing will create an adversarial relationship with them. If they see you as the adversary, they will also see testing as the adversary. Give them the benefit of the doubt, and assume that they want their code to be tested and they want a positive relationship with testing and you.

7. Tell the rest of the team that they can't test their application because they are biased.
If there is any generalization in testing I would like to kill dead, dead, DEAD, it is the assumption that developers can't test their own application because they are biased for their code. This is a magnificent way to create a testing silo. In actuality, I've never seen developers be more ruthless than when they were testing each other’s code. Whenever there has been too much testing for me to handle alone, I've scheduled an hour or two for developers to test their application and they have never let me down. Although developing good testing skills takes practice, developers are perfectly capable of doing it. Assuming that they are incapable of testing the application they work on is to give them very little credit. Involving them in testing activity will help them brush up on testing skills and think about testing more than they would otherwise.

Cultivating a collaborative relationship instead of a competitive relationship with a software team is important if testers want the team to have a good relationship with testing. This starts with the tester. Testers who are only willing to see themselves in an adversarial relationship with their team might have success at finding bugs, but it is also likely that they will alienate the rest of their team's relationship with testing. Software testing is hard enough. It's better to be on the same side as the rest of your team and to help them understand the relevance of testing.

Files: 

Seven Ways to Make Testing Irrelevant on Your Team