Do your bugs only glow when its dark?

Have you ever been in the situation where no-one else can find and repeat the bugs you find? Perhaps you have a canny knack of finding unusual bugs, or maybe it’s time to improve and update how you write bug reports!

I do a lot of offsite exploratory testing in very aggressive timelines and consequently I have to admit, I sometimes start making basic mistakes.

My common mistakes are:

1) I don’t write the bug report up straight away

2) My bug reports are not detailed enough

3) I underestimate the time it takes to write up defects

4) I don’t use a defect tool

You can imagine, when you’re working offsite without even meeting the developer, this can lead to all types of complications. So I need to put myself in that poor developers shoes and make my bug reports as clear, concise and as detailed as possible.

I think it’s tempting when there is little formalised structure in testing to overlook writing a disciplined bug report, but it’s worthwhile to you and the customer. I mean what’s the use of paying someone to find bugs when no-one else can find and fix them?

Anyhow to prevent myself repeating such unforgivable mistakes, I have developed a set of guidelines to follow.

Offsite Exploratory Testing Guidelines to Bug Reporting

1) In the estimate to the customer, make sufficient time to write your bug reports as you go. It’s impossible to know how many bugs you are going to find but you can do a bit of math. If you’re planning three    days of testing, and you find 100 bugs @ 10 mins average, then that’s two days of your testing filled up with just writing up reports.

2) Agree on a detailed bug report with your customer. Try if you can to get agreement with the developer. Try and include as much background information as you can. There has been a load written on what constitutes a good bug report, so I won’t repeat it here.

3) Don’t delay; write up the bug report straight away. This is hard when you’re in the middle of some exciting analysis and you really just want to keep testing in the timeframe you agreed on. But trust me; it takes longer to write them up at the end, when you have to review heaps of cryptic phrases in Session Tester or in your notebook. A capture tool may be helpful in recording data, but if you leave reviewing to the end, it will add additional time and effort to the testing

4) Encourage customers to use a defect tracking tool. It saves everyone a lot of headache and heartache. There’s lots of open source defect tracking tools out there. TRAC and Bugzilla are the two most common.

2 thoughts on “Do your bugs only glow when its dark?

  1. I couldn’t agree more Anne-Marie. I’ve made the same mistakes of not raising the bug there and then and forgetting crucial parts of it. It certainly doesn’t help the programmer fix the bug with crucial information missing.
    It’s amazing how long raising bugs actually takes.

    I now have Notepad open at all times…invaluable for keeping a record.


  2. Nice post Anne-Marie,
    while testing its always good to track your execution steps, so that we can write detail steps in order to reproduce the bug, writting detail bug report needs time but it will save your lot of effort in the end as you said.
    it would be great if you write the effect of bug in overall perfromance of the application, how it will effect different clients,it will help developer to fix the problem and provide good stats to the management as well.

    Nice post again , keep it up 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *