Bug reporting: 8 ways to annoy your software development team

March 14, 2012 at 12:04 pm | Posted in Programming, Ramblings | 18 Comments

As usual this blog post should be read with a large grain of salt. It is a collection of bad practices I have seen during many software development projects. There are positive exceptions. For example when the testers are part of the development team and the whole team is committed to delivering valuable software instead of two opposite parties trying to fight each other. Having said that, the ugly situation mostly happens in fixed-price contracts where the bug versus feature discussion often takes place.

Disclaimer: all the examples are made up. Any resemblance with bug reports from projects I did is pure coincidence 😉

So here is some practical advice for acceptance testers on how to maximally help a software development team:

1. Since you have spent a lot of time finding this bug, prioritize it at least as Major. Of course Critical or Blocking is even better so that the development team will realize it is urgent and pick it up immediately. Luckily most bug tracking systems (for example JIRA) have priority Major as the default setting so you don’t have to spent too much time thinking about this. Example: a missing help text on what the field ‘zipcode’ means should be marked as major because it is going to leave the end user clueless.

2. Make sure that the description of the bug is short. A single word is better than a long descriptive sentence. The advantage is that it forces the developer to open this issue every time to understand what it means. This will help him to not ignore this bug just by reading the description. For example ‘Login’ is a much better description than ‘Login failure when I fill in a non existing username’.

3. Don’t let yourself be fooled and use improvement, change or new feature when filling in the issue type. Everything you find is a bug. Otherwise your organization (the customer) will have to pay for it, especially in fixed-price contracts. There are two situations to be handled here: if it is in the specification, then it obviously is a bug if a feature is missing or not accordingly to the spec. If it is not (clear) in the specification then you can always defend it by saying ‘it is obviously that this is not acceptable for the end user, so it is a bug’.

4. Never provide details in your bug report! This might put developers on the wrong track. It is much better to let them find out themselves what caused this problem and how to reproduce it. After all, they are the experts. That will also give them a strong incentive to deliver better software the next time. A good example is of course the good old ‘Doesn’t work’ or ‘Program crashed’.

5. You can (and should!) often re-open an existing bug-report. This is just a practical thing and saves you some time. Especially if you have a good generic bug description (Like for example ‘Login’ mentioned before) this is very convenient. But don’t be bothered if the new bug isn’t related to the old one. You are just helping the developers to limit the total amount of bugs and re-opening fixed issues gives them a nice historic perspective. Software developers like re-use and DRY (Don’t Repeat Yourself), so should you as a tester.

6. Another practical tip: combine multiple bugs in one single bug report. Again you are helping the developers here because many bug reports might give a bad impression. It also helps to give them focus: suppose the login functionality in your application doesn’t work, then it is also a good moment to combine that with fixing a spelling error on that same page and probably adjust the colors a bit so they are more conform the specification.

7. Bug-reports are also great ways to communicate, especially with introvert developers. So you can create a major bug with a question like “What does the specification say about this Cancel button?”. That will help them to think about the spec, enable single/double/triple loop learning, etc. It might take some time, but someday they will appreciate what you did for them.

8. Another great way to stimulate software developers in a positive way is to use bug reports to give them some good advice. For example “Feature xyz is not very easy to use.” This example can be easily marked as ‘Critical bug’ and it will sparkle the creativity of the development team to come up with a great solution. That is also the reason that you, as a tester, shouldn’t give away any information on how this feature should be improved because you want to empower the developers instead of extinguishing  their creativity.

I’m sure there are many more ways to improve the communication between testers and software developers. Don’t hesitate to share them!



RSS feed for comments on this post. TrackBack URI

  1. Hi Maurits,

    I was just browsing the various bugtrackers (5 Jira, 1 testtrack) and then I saw your new gem 😉 Hilarious and so recognizable… oeps.. completely has no resemblance with real projects ofcourse 😉

    Real fun is combining point 5 and 6: Open a existing bug report, and then add a new description which has nothing to do with the original bug.

    Luckily I have now my default answer in Jira; Resolved: Won’t Fix 😀

  2. I had the 5 + 6 happen to me yesterday, LOL

  3. Totally. Happens to me most of the time.

    I do have another one: Just dump a whole mail discussion into the bug tracker and re-assign it to your developer. This way he can puzzle out the actual defect or failure or features or whatever they want.

  4. The worst I got was when they log that the software is broken and then it is just one button that is not working, which turns out that the button is disabled for a reason.

  5. I don’t necessarily agree with the post completel, especially the points about not providing enough details and reopening an existing bug. This does nothing more than wasting precious development time which could have been used to fix real bugs and quickly so because details were furnished properly. Its in my DNA to ignore bugs that have no details in them or have been reopened for the fun of it. This kind of sadistic fun seeking is common among testers i feel.

  6. Bug without details is actually causing developers to spend more time to reproduce it. And for reporting multiple bugs under one bug report is double edged sword, it keeps bugs number but developers loose that feeling when they are fixing couple of bugs with one commit:-)

  7. Great List!

    A couple more pieces of advice:

    When setting up a test machine, make sure that your OS/browser/framework is at least three years behind everyone else in your organization – restoring from an old archive image is a good way to ensure this. It should of course also have completely incompatible networking, printers, devices, shares and permissions to any live systems.

    Needless the say, the same goes for any test data.

    Cross-post any issues to any Apple forum where the default reply is always “you can’t possibly have a bug, everything works on mine”. It won’t help but it may reassure you that everything is well.

    Don’t waste time testing the actual figures, or you might get to understand what they mean. Color is more important than content.

  8. You forgot the ‘obvious to a 2 year old’ reports. E.g. Screen is all black during a power cut. Does not read disc when inserted upside down. Norwegian Sign Language is not available in the language options.

  9. I had someone once call me up about an application I had written:

    Me: Hi, Mike speaking.

    Her: Hi… the thingy doesn’t work.

    Me: Thingy?

    Her: You know, the thingy that does the stuff when I click it?

    Me: You need to be more specific. What screen? And what does it say on the thing you’re clicking?

    Her: Well it showed an error.

    Me: (thinking the text of the error might give me a clue what part of the software involved) What did the error say?

    Her: Oh, I didn’t write it down. I just clicked Ok.

    Me: What were you trying to do when you got the error?

    Her: My work.

    It went like this another moment and then I just told her I would come over and look. So I had to go all the way to the other building, only to see that it was just telling her she had forgotten to enter the contact’s name when creating a new contact record.

    When I told her…

    Her: Well, can’t it just know?

    Some people should not use computers.


  10. Other ways that I’ve received recently include:

    – Incoherent/broken English reports (“cannot workset be putted when is pickuping not disable”, and when clarification is requested, getting the original report back (“problem already describe in original report: “cannot workset be putted when is pickuping not disable”)

    – report “missing data in database”, with the description field being a screenshot of a query taken at site

    – report behaviour as “incorrect” even though it complies with requirements, because *other* projects did it differently, and “the other way is better”

    – report “communication problem as per attached logs”, and attach logs with no communications problem. When asked for details, say the logs were too big to attach to the bug reporting system, so you attached the logs from the previous day, since they would fit.

  11. For how to report bugs effectively see Simon Tatham’s http://goo.gl/4Xue

  12. Dude please don’t post guidelines when you are not competent to do so! There are a lot of idiots out there and some of them may really believe your words!

  13. Half of the recommendations totally prove your impotence in QA field.

  14. That was a funny post. However, I’m worried about some of the comments.

  15. You forgot one! Create a bug with a suggestion for a fix, and when it is complete and you realize it creates a much bigger bug since it ruins the functionality of the product… create another bug that requires the developer to revert back to how he had it in the first place.

  16. This is a ridiculous article, dev time is too much precious to let them wasting time figuring what the bug is. This can’ t scale, it needs more than that …

  17. My brother suggested I might like this website. He was entirely right.
    This ost actually ade my day. You can not imagine simply how much time
    I haad spent for this info! Thanks!

  18. And never ever attach a screenshot to a bug. Developers like to guess what you mean and where the bug occured.

    Or, if you want to do something good – check out Usersnap for screenshots on bugreports: https://usersnap.com/

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

Blog at WordPress.com.
Entries and comments feeds.

%d bloggers like this: