Categories
benefits BlogRoll tools

Bug Tracking Tools Explained

Like it or not, all software has bugs.You may not know about them but they are there..lurking in the darkness, ready trip up one of your innocent user who has just gone and purchased your software.
That’s why you employ a software tester. A software tester’s job is to find as many of the bugs and report them to you and the rest of the team before they can do untold damage to you and  your software’s reputation.

You can report bugs in as many ways as there are to communicate. You can write the bugs up in an email, on a piece of paper, in a spreadsheet (see my previous post on spreadsheets). You can even directly speak to the relevant person and directly show them the bug.

Or you can use a bug tracking tool.

So why do you need to track a software bug and whats so great about a bug tracking tool?

Software Bug Workflow

Well, just as a normal bug goes through several stages in its life such as egg, nymph, larvae and finally adult, so to does a software bug go through its own lifecycle or workflow. Redmine the opensource software I use as my online bug tracking tool,  uses the word workflow so I’ll use that term in this post.

Typically a simple bug workflow goes as follows:

Bug WorkFlow

Where:

new is when a tester creates a bug report

open is when a developer  accepts the bug report as valid

fixed is when a developer indicates that the bug is fixed

tested is when a tester indicates the bug has been tested

closed is when a tester accepts the bug has been fixed and the report is now closed

This is a very simple workflow. Alternatives to the workflow can happen when for example,  bugs are rejected by the developer  or a bug fails test and the tester places the bug back to open state. In fact, it can get quite complicated if you let it.

Most bug tracking tools will let you modify or create your own stages and workflows, but if your new to the concept of a bug tracking tool, its better to select a simple existing workflow and use that for a while to get used to what works for you. Redmine, lets you chose a preexisting work-flow.

A bug tracking tool then allows a tester to create a bug report and monitor its progress as it goes through its workflow

So whats the big fuss? Why not just use a spreadsheet or email?

I’ve personally benefited a lot from bug tracking tools. Here are some ways they’ve helped me.

Benefits of a bug tracking tool

1) Its easy to keep track of one bug, but keeping track of many bugs is hard work. A tool helps you easily find out what bugs are still open, fixed, closed. Bug tracking tools normally allow you to sort and filter your bugs and create reports on the bugs.

2) You can track other stuff about bugs, such as how important they are and who is fixing them. This can help you prioritise which bugs are important and require urgent fixing.

3) You can start seeing clusters of bugs which indicates there may be underlying issues in parts of the code

4) Lots of people can see the status of the bugs, not just the tester and the developer. The overall bug status can be quickly reviewed by many avoiding nasty surprise syndrome (NSS) at the end of development/testing.

5) Sometimes not all bugs are fixed in the current release but will be fixed and tested in a future release. This means long after software release the bugs still need to kept open and tracked. A bug tracking tool ensures that these bugs are not overlooked in the future.

6) A bug tracking tool can centralise information. Often a bug tracking tool can be used to track new features as well as issues and can act as a document repository. Redmine offers many additional features such as document repository and wiki.

7) A bug tracking tool can improve productivity by increasing bug awareness and responsiveness. It is also handy when a project is scattered geographically and works across different time zones.

As I’ve mentioned in previous posts, there are many open source options bug tracking tools out there, so if budget is an issue there is no need to spend a lot of money on an top end commercial tool.

And of course, a tool is only as good as the developer and tester using it and will fail miserably if no one is willing to use it, so perhaps if your thinking of adding such a tool to your testing toolbox, speak to the rest of your team first to find out what they are looking for in a tool.

Categories
BlogRoll Freelance

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.