How can I make my relationship with QA less adversarial?

Question

Throughout my career, I've had varied amounts of success getting along with QA. I admit that I can take bug reports personally, but usually when they're crafted in a freeform style that is worded more like a complaint: "This process is STILL not working!", without enough information to reproduce the defect.

I'm willing to work on my sensitivity to criticism, but I'd also be interested in tools and techniques that depersonalize the QA process and encourage informative bug reports. Currently, bugs are reported via email or sometimes by walking up and verbalizing them.

Any tools should be: free as in beer and easy to install/low administration. I'm also open to blog posts, books or articles on how to desensitize myself to bug reports.

Answer 1

I'll leave tool recommendations to someone else, as what we use isn't "free as in beer".

Your first priority does need to be fostering the ability to detach yourself from the process. This can't be a personal issue. That being said, try to communicate with QA (either personally or through the CoC) that editorializing in the bug reports is counterproductive ("This process is STILL not working!", as you wrote, is not helpful). The purpose of the process is to increase the quality of the final output. Such exclamations do not further that goal.

Answer 2

1. Get a real bug tracking system. FogBugz, Bugzilla, whatever (I am not a shill for Spolsky, but I will say that FB is by far the easiest to use system for our testers, and easy to use really matters for them). Those make it a ton easier to define QA processes and bug reporting workflows. This should help make it a less personal interaction between you and your testers.

2. Don't ever take it personally. I get bugs all the time, both through our bug tracking system and through personal interactions. Regardless of their tone, I always respond, "Thanks for catching this, I'll look into it". They may be having a bad day, you may be having a bad day, who knows? If they don't provide enough information to reproduce, and they're not providing this information on a consistent enough basis, see #1 (get a real workflow and stick to it).

Answer 3

The best way I've found ti handle such statements as "its not working" is to use a similar terse question in reply. "Thanks, though could you help me by telling more about what you found?". Then leave the ball in their court.

If there's a complaint that you haven't reponded you can point to your request for more information. Don't do someone elses work, its the job of QA to define what specifically hasn't meet the quality they are responsible for assuring.

Answer 4

Forget tools. This is about communication. You need people who have the discipline to tell you exactly what is wrong, how they got there, and any specific conditions that led up to the event. You also need to be able to give feedback when people write something like "It's broken". Development and QA management need to talk about what is needed from both sides.

Regarding sensitivity, I've found that attitude trumps all. Every time you see a bug report, you must start with the attitude that "This is not a personal attack; it's an opportunity to solve a problem and learn something." Once you set your frame of mind, your responses will follow.

Answer 5

I have had the absolute best experience with QA when working together to solve bugs and/or analyse them. Neither programmers nor QA engineers are the easiest people to get along with, and there is some fundamental tension between these groups.

When I had problems with bugreports filed against my code is walk over to them and ask what exactly they meant, and/or walk me through the steps to reproduce them. A lot of the time the problems was in a mismatch between the way I read some requirement, and they assumed that would work. You talk, like human beings, not according to some formula, and you figure it out together (agreeing to disagree and letting someone else make a call is an option here).

A bugreport mailed or filed in some bugtracker may feel offensive in the way it is worded, and it most certainly will since it is pointing the finger at "your baby", your creation. Talk to the person filing the bug, and you might notice a common goal: to make the world/software a little better.

My attitude toward QA paid off in that it became a relationship of mutual respect (although neither of us would admit that :P), instead of screaming 'not a bug', I'd walk over to them first. Instead of instantly claiming something was a bug they'd walk over to me first. In the end, we're all doing our jobs. It's programmers to write software, and QA engineers to shoot holes in that software. And I'm very thankful to have worked with some very bright people telling me what I did wrong.

Oh, and never ever use the phrase "It's not a bug it's a feature".

Answer 6

Do you have sharepoint (or a wiki, etc.) where you work? It would be quite easy to set up an issue log there for all to see at no cost. I'm not going to get into tracking tool selection, there are many out there. Check SourceForge or Codeplex if you want free.

The biggest thing to help is to definitely NOT take it personally - they're doing their job same as you. Setting a format for "acceptable" bug reports would help, even with the email you're using currently.

At a minimum they should include:

• Nature of Defect
• Severity (usually 1 - 5 with 1 being "unable to continue" and 5 being things like spelling errors
• Steps to reproduce.
• Screenshot(s) if available.

Any decent QA person should be doing this already and testing to a script.

Answer 7

Just like developers, QA have (or should have) minimum standards to adhere to. When raising an issue they need to provide:

• a repeatable test case;
• a screenshot; or
• a description of the problem and any pattern if it is inconsistent or other not reproducible.

If I have to go over to QA and ask what the problem is or how they produced it, I get annoyed. "This doesn't work" just isn't good enough.

In one system I developed (a Web reporting system) I generated all the input data on each generated report. When QA ran a report and noticed a problem they could go to a blind URL and download a ZIP file that contained:

• the definition of the report;
• the template used; and
• any database input.

On the dev side I wrote a tool that could rerun the report based solely on that ZIP file. This had several effects:

• If QA raised an issue, I could say "wheres the ZIP file?";
• Once they got into the habit, it became far easier to raise an issue; and
• Problems were trivial to reproduce and retest by developers.

The effect was profound and I think that highlights one key issue: developers don't like it when things are hard to test, hard to reproduce and so on. Likewise, QA people don't like anything that makes their job harder and they like anything that makes it easier.

So my advice for working harmoniously with QA comes down to:

• use an issue-tracking system. This is absolute #1 priority. Everything needs an audit trail;
• have someone in charge of QA that is responsible for the team. They can address issues of insufficient detail provided in QA-raised issues. Rather than going to each tester, go to this person and let them deal with it as they see fit. For one thing this should lead to consistent standards;
• provide as many tools and diagnostics as possible to QA to make their life easier. It'll make your life easier too;
• don't judge developers or QA on pass rates. Don't even produce such statistics. They lead to an adversarial rather than collaborative environment. You are (or should be) all on the same team;
• have weekly defect meetings between QA, development and project management to discuss latest, resolved and outstanding issues at a more macro-level. This can be useful for both a project tracking point of view as well as generally getting a feel of any major issues or problem areas you may have.

Answer 8

Try to involve them more in the project processes. We have regular retrospectives where QA people are given equal voice with developers. They frequently suggest ways in which we can improve processes that make their jobs easier and make it easier for them to ensure quality. And more importantly, these suggestions are debated and (if agreed) adopted. This makes QA and dev part of the same process and not in opposition.

It's also important for devs to take responsibility for their code. If QA are finding lots of bugs in an area, then it's because the dev did a shoddy job of writing it. It's not because QA are being difficult. The dev team should all recognise this.

Answer 9

I agree with Paul Williams. It sounds like the process QA is using to submit issues should be improved. Emails, and verbal communcation of issue status suggests room for improvement. I also agree with his advice of Development and QA working together to improve the process and communicating. I'm a QA engineer and have been doing this for over 10 years now.

You sound very mature and big props to you for not blowing up on anyone. It's ok to write words to the effect of "It's still broken" but clearly the QA person needs to learn more tact.

I completely disagree with the message AnthonyWJones is sending. I realize every company has their own culture, but the way he phrased his response suggests a "Throw it over the wall, QA is responsible for quality, not me" attitude. Nothing wrong with that specifically but it doesn't help if you want to foster a coopertive and cordial environment. A healthier culture is one where the entire development team (which includes QA) share equal responsibility for quality.

Answer 10

Read "Working With You is Killing Me!" Realize people just want to get through the day, earn a buck, and go home. "Don't sweat the small stuff."

Answer 11

As a QA person who is basically a developer (Automated regression testing), I think I've been able to see both sides of this issue.

As several others have stated, this is a communication issue, no tool is going to solve it. Tools such as bugzilla, improve the efficiency of the communication, but they still require that both parties work to keep the lines of communication open.

I've seen that developers often have trouble with taking bugs personally, which leads to brushing them off as 'unimportant', 'Edge-cases', 'As-Intended', etc. when the issue is in fact a problem. Even if the issue is actually unimportant, simply sharing your evaluation of risk/reward in fixing a bug helps to foster better communication.

Conversely, QA guys often leave out details of the bug and steps to reproduce it (myself included). When you as a developer run into missing details, it is your job to ask us for more detail (and please ask us kindly and promptly). The worst feeling is when you write up a bug and send it off to a developer, then hear nothing back for a few days, and it gets closed as 'Unable to Reproduce'.

In the end, the key is prompt and kind feedback on both sides. If I (in QA) am working with a developer that always responds when I send him a bug and seems happy to help work through the issue, I am much more willing to take the time to give him all the details I can.

Answer 12

I don't think tools can help you a lot.

Ask QAs to write steps to reproduce the problem, preferably starting with

• Run application
• Click ...
• etc.

This will structure their thoughts and help you to understand what QA want to say.

Answer 13

Tools to depersonalize seem like the wrong direction to me.

• don't take things personally
• be thankful that they found a problem before your boss or the customer found it
• come to the relationship with respect for the testers; think about what they are adding to the development process this
• express your frustration in ways that might be taken better:

"Gosh, that seems like a really important bug we need to fix. Thanks for finding it, dude.

I'm a confused about how to reproduce it. Do you have any ideas? or more information?"

• Remember, you are on the same team:

Wow, that bug report you wrote was really great. It saved me tons of time in isolating the bug. Thanks!

Wanna go out for a beer? Beer, as in free?

etc.

Answer 14

For me as a remote team member bug tracking tools are inevitable. And in my experience they really help to 'depersonalize' the process.