The Software Testing Club recently put out an eBook called “99 Things You Can Do to Become a Better Tester“. Some of them are really general and vague. Some of them are remarkably specific.
My goal for the next few weeks is to take the “99 Things” book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.
Suggestion #39: Build a good relationship with the developers. – David Wardlaw
In many organizations, the test team has often been seen as the hold-up when they are too aggressive; they are blamed for holding up shipment of new features or releases. Sometimes when bugs come in from the field, the test team is the one who gets the blame (“why didn’t you catch that bug?!”). Reactions often range from small incremental fixes to try to do better to sweeping organizational and process guidelines that put up lots of “C.Y.A.” barriers. If you have lived through any of these types of environments (yes, I have) then you have also probably had your share of antagonistic relationships between programmers and testers.
The great thing is that it doesn’t have to be this way. If organizations will embrace a culture where quality is everyone’s issue, and when an issue makes its way out to the field, everyone has the same level of responsibility, then these attitudes are less frequent.
Workshop #39: Stop thinking in terms of “us versus them”, even if you are the only one who makes the change
The simple truth is that no one can change an entire organization’s attitudes by themselves, but they can set the stage for others to follow.
Think of the manner in which you interact with your development team. Do you have the freedom to go to a programmer and discuss an issue? If so, go ahead and do that when you can. Follow whatever processes and procedures are mandated, but try to have informal conversations and see if you can help resolve issues more quickly with direct interaction.
If you come from a more formal environment where there is a clear division between development and testing, try to do some “undercover work” with a willing programmer. You may need to spark this by starting a conversation at lunch or after work in a social setting. The point is, try to see if you can interact more directly with programmers and have real conversations. Find out what boosts your credibility with them, and then follow up and show them you are doing what they are hoping to see you do.
Try to see if there is a way to get testing as far up front as possible, as far back as initial requirements. As I mentioned in a previous post, my company uses a strategy that we call a “kickoff” and is based around the Three Amigos meeting approach. Here, we all get together and, early in the process, make sure that we understand what the requirements are and what “done” looks like (as best we can) and then we try to work together through the entire process. This way, we can refine and clarify what we want to do and how we do it as the story progresses, and not find ourselves at the end of the cycle wondering “wait, am I looking at the right things?”
When it comes to finding and reporting bugs, the most important thing to remember is that programmers are human. They are not superheroes. They are not infallible. They want to put out the best product possible. Make sure that editorializing or blame is nowhere to be found in bug reports. Just state the facts, provide supporting evidence, and dispassionately make the case for what need to be fixed. If there is a disagreement, have a conversation with the programmer and see if you can come to an understanding. Ask for clarification, have them show examples, demonstrate what you see, but again, focus on the larger goal, which is to put out software the customer will be happy with.
If the organization supports it, schedule pair programmer/tester sessions, and work on stories in real time together. Test while they code, have them explain what they are doing, and ask questions while they do it. This option can have tremendous results, since the turnaround time from issue to fix/confirmation is often much faster than programming and testing as separate activities. If the organization doesn’t support this approach, again, find a sympathetic programmer and suggest the idea. Try a pilot on a story or a bug to show proof of concept to those who are skeptical. More times than not, positive results, and credibility, will sway skeptics.
If I want to develop a good relationship with programmers, that’s what I have to do… develop a relationship. It will likely take time, especially if there has been dysfunction in the past. If you would like to do the same, do everything possible to get rid of blaming others. Encourage others to get out of the blame game, too. Encourage the entire team to own quality, and champion approaches that help get testing as early as possible into the process. More than anything else, follow through and collaborate with programmers wherever possible. Take the time to build credibility. That’s the real foundation of a positive programming and testing relationship. If other programmers see us as someone they can work with effectively, they will. If other testers see that we are working effectively with programmers, they likewise will be interested in what we are doing, and maybe, just maybe, the culture will change.