Write bugs that get fixed

It seems simple enough- find an issue, file a bug, wait for it to be fixed. The tough part should be finding the bug in the first place, but sometimes it isn’t.

1- Time constraints. When deadlines loom, the team may be anxious to get the project out the door and ignore “minor” issues that can be fixed post launch.

2-Complexity. Even simple sounding bugs have have complex integration with other functionality or require a lot of rework – and no one likes rework.

3- Dismissal. No one likes to hear this one, but it happens. Sometimes bugs get dismissed because a) the developer doesn’t trust the QA or hasn’t seen the issue b) it feels like a rare corner case c) it is hard to reproduce d) there are a lot of other demands on the team at the time and your bug simply falls off the radar.

How can we avoid these issues?

We can write clear bugs. Reproduction steps are one of the strongest tools we have. One of my favorite QA interview questions involves getting candidates to write reproduction steps for an unexpected action. It is a really important skill for QAs. Project managers and engineers need to really understand how we got to the issue we did and be able to see it themselves- not to mention how much it helps us if we have to explain our bugs to someone.

We can follow up on issues. How many times have you written a bug just to let it slip by unnoticed while you found more issues? Checking on the status of issues isn’t as exciting as finding new ones, but it is important if you are trying to get something fixed. If a bug gets put in deferred, make sure you know why. If it is fixed- does the fix match the documents?

We can be knowledgeable. Sure, we aren’t developers- but it helps if we know about about the software they are writing. If there are lots of false alarm bugs or low priority issues labeled as high priority, the team will start to trust us a little less. Knowing about the documents, the software and the issue make you a much more creditable source and seems to help your bugs get fixed.

We can “file” some bugs off the record. I’m not really promoting this- especially if your company is big on formal policies. But, if it makes sense for your team, letting developers know about smaller issues first, offline, not only gives them a head start, it puts us all on the same team. We aren’t filing bugs against developers, we are working with them to make sure everything runs right.

Does anyone else have tips for making sure bugs get addressed?

Advertisements

2 responses to this post.

  1. @Devon Smith
    Good Post Devon.

    Does anyone else have tips for making sure bugs get addressed?

    I usually add a Risk or Customer Impact field to bugs (atleast the important ones) indicating the risk involved if the bug is not fixed. Elaborating on the customer impact as a result of this bug has helped me many a times. In some cases, if the exact use case of the customers is known, it is a good idea to add the use case in the bug as well. At times, the bug becomes very lengthy and detailed, but it is worth for getting it fixed 🙂

    We can “file” some bugs off the record. I’m not really promoting this- especially if your company is big on formal policies

    I think filing some bugs off the record should be promoted to a great extent. This is also known as Mipping. Imagine the amount of time spent (wasted at times) investigating, reporting, negotiating and advocating fixes for bugs that are less important compared to critical ones. I wrote a small post on this a while ago – http://curioustester.blogspot.com/2010/02/bugging-story-on-testers-credibility.html

    Regards,
    Parimala Shankaraiah

    Reply

  2. […] Report results:  Carefully fill out your bug report. Stick to a bug filing standard. Spell check. Make sure that anyone could understand your bug and […]

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: