Building Relationships with Developers

From my own experiences and from watching several webinars, there is a less than ideal relationship between Developers and QA engineers. Problem is, it's not hard to see why.

By and large, I have a great deal of respect for developers. Elegant and sophisticated code takes a great deal of time to write, but only takes a short time to test. Like writing, painting, poetry, or playing an instrument, writing good code is an art. Developers pour their intellectual sweat into a project then offer it up to their peers for review. It takes a lot of courage to reveal your code to a public audience, day after day, and say "Critique this." It's a big responsibility to take someone's craft and offer feedback. It's a process that should be treated with respect. But, in many cases, I don't think it is.

I've seen and heard it too many times, "Ha! I found a bug!" "You're not getting that sort of thing passed me!" "I knew I could break it!"

I do not agree with the idea that the role of the QA engineer is, "To break shit." Any poo-flinging monkey can break things. I believe the QA goal is to make sure "we" deliver software that meets the customer requirements. It's not about fault, laying blame, keeping score on the number of bugs, or trying to stop a deployment. It's about using the software and making sure it does what the customer has asked for in a meaningful and useful way.

Of course issues will be found, but not every issue needs to be corrected. Additionally, I have made the comment many times, in a joking way, "That bug was like that when I got here." QA doesn't introduce bugs, we document them.

I take no personal satisfaction in finding bugs, watching a system crash, or finding fault in the work someone has done. I want to see the software work. I want to see it take data and produce results.

At the same time, there is an appropriate way to comment on bugs. Running around saying, "The tool is broken!", or "This doesn't work.", or "This crashed.", is a sure fire way to get the dev on the defensive. This is how adversarial relationships begin and why QA in many ways gets a bad reputation. Plus, it's a stupid comment.

It's far better to say, "When I do this, I get this result." Or, "When I tried this, I got this error message." Or, "I tried this and I'm not sure the answer is correct, can you go over it with me." Be respectful of the work they've done. If you think being a Dev is so easy, take up the mantle yourself and see how you feel about the scrutiny.

Not all bugs are code either. Unexpected results can just as easily come from bad data, system glitches, poor performance, networking problems, outages and other factors. So, go easy on the blame thrower.

It's better to work with the developer and build a partnership that makes each of you successful. Make sure you hand over all the information the dev needs to recreate and fix the issue. I did this, with this user, this item, on this screen, following this series of steps. If they can't reproduce it, bring up the screen and walk through it together. Ask if there are tools you can run that will get better information for them. What can you do to help them? Don't throw your problem over the wall.

Further, bring up your testing methodology before the code is handed off. In planning meetings, I've asked, what is a good way to test this? Or, how will this look on the page? Or, it sounds like I'll need to do "this" in order to test, do you agree? If I understand this correctly, I will need "this." If I need test data, I will bring that up. Or even better, I will ask for a way to get the data myself so I don't have to derail anyone more than necessary. It's a learning opportunity.

There should be a conversation where everyone has input on what's happening. Sure, I have my plan, and not everything needs this level of discussion, but when you are clear in what you are doing and what you need, everyone can be on the same page. The devs will already be aware of your process and will test that themselves. They won't be hit out of left field with, "Why on earth did you do that?"

I have noticed that very quickly the devs and I are working together, not against each other. They know I'm not trying to play games and trick them. I know they are testing portions before I even see them. We are helping each other simply by communicating our intentions.

This may seem silly, but I feel it's important to compliment the devs on their code. It may not mean anything, but it means something to me. I want them to know I appreciate the work they are doing. A good solution or good experience should be pointed out. Maybe it's something we can use in other places on the site or for other customers.

"I worked with Joe on ticket X, and it works great."
"I tested X, and it works really well."
"I tried out X, and it looks great."
"Feature X, is very cool."

In order for a team succeed, they must work together. They should understand and respect each other's contribution. The ultimate goal is to get code out the door. No one wins when a deployment is delayed or an issue is found in Production. No one wins when people work against each other, stand in the way of progress, play games against each other or even try to sabotage each other. We all want to release great software and that takes a village.