Developers and testers often have a contentious relationship. This isn't too surprising when you think about it....
Part of the role of a traditional tester is to find out what's wrong with the code – something that the developer has most likely spent many long hours perfecting. The tester is criticizing his baby! Having spent years of my career in both roles, I'm well aware of the emotions on both sides of the equation. However, by learning some techniques, developers and testers can learn to avoid conflict and discover that they are often one another's most important ally.
Break down the wall
Both in agile methodologies and in application lifecycle management (ALM), there is the ever-growing trend of breaking down "silos" and becoming more collaborative. No longer are we to "throw code over the wall" between development and test. However, regardless of your organizational structure or methodology, I maintain that this "wall" does not need to exist. It is about attitude.
In an organization where there is a "wall," the developers and testers are critical of one another. The developers pass the code on to the test group. The test group pat themselves on the back for finding so many bugs, complain that the code was delivered to them too late with no unit test and that the project can never be released because the quality is so poor. The developers claim the bugs are user errors and that the testers are wasting time testing areas of code that aren't important. In general, these two groups are not respecting the value that they are each bringing to the table. Rather they are pointing fingers at one another, claiming the other is "the problem."
Even in organizations where the tension is not as pronounced, there can be a general lack of good communication between development and test. Working on agile teams where there is more of a partnership between a developer and tester helps, but it doesn't always solve the problem entirely.
Learn the craft of the other
One way to appreciate the value of your partner in a developer-tester relationship is to spend some time in the other's shoes. As I wrote in my response to a user question about the importance of code vs. test, they are both important. At the very least, a developer needs to learn how to thoroughly unit test his code. By also learning the art of exploratory testing and other testing skills, such as performance testing and security testing, the developer will know better how to design his code, not just for fewer defects, but for testability.
Likewise, the tester who learns the craft of software development will be highly valued. Not only will this tester be better equipped to help with automation of procedures and tests, but she will go beyond testing by being able to provide some insights into why a troublesome defect is occurring. Understanding the architecture of the application helps the tester make educated guesses about defects and then further test those guesses with additional testing, proving or disproving a hypothesis.
Use respectful communication
Regardless of your skill level, or that of your counterpart, in order to have an effective relationship, you must communicate with respect. In any job where the role is to assess and critique, it's important to communicate the findings with sensitivity and diplomacy. Though it's natural for a tester to feel proud of finding a major bug before it reaches production, there's no need to gloat about it, particularly if fixing that bug causes a major setback for the developer. Can you imagine a doctor communicating to his patient about a tumor he'd found? The patient might get rather annoyed if he came in with a big smile on his face saying, "Guess what I found? Maybe if you'd taken better care of yourself, this wouldn't have happened." What's more, the patient would want to know as much as possible about this tumor. The doctor not only has to deliver the news, but must do it with sensitivity and with plenty of data to back up his findings. The tester, similarly, needs to feel prepared to communicate the bugs he finds effectively. There's no need to pass judgment on the developer, but instead to help the developer by giving him data and supporting him with follow-up tests when the bug has been fixed.
Similarly, the developer needs to treat the tester with respect and not become defensive. If it appears the tester is focusing on the wrong area of code, the developer should explain this, not in a condescending way, but in a way that will help both partners get on the same page. When the tester finds bugs, the developer should show appreciation, and maybe work together with the tester to understand how he was able to uncover the bugs. If there's an area that is particularly prone to problems, the developer and tester might work together to create an automated regression test suite.
Operate as a unified team
Developers and testers must learn to operate together as a team, regardless of their organizational structure or methodology. This can be done using respectful communication and working together to achieve the overall goal of creating a high quality application.