Question

What should a tester enter in a bug-tracking database, and how should it be marked?

We just got FogBugz and we love it. However, we are newbies! My manager loved it so much, that our tester is now entering everything she finds in FogBugz.

At first, everything, no matter how small and regardless of the nature of the issue she saw, was entered with the defaults. That means that they all had a Category of BUG, and Priority of Must Fix.

Many of these cases that got entered were things like the following:

•I think the font should be bold here… •This does not seem consistent… •This page needs a return link… •This color is a little had to read… She entered so much stuff it was difficult to find the real bugs. I had to read like 100 cases to find the 4 or 5 cases that really were important.

Misspellings, crashes, missing functionality are all bugs, but are the above type of cases really bugs? I am still not sure how I feel.

We discussed the matter at length. She has started setting the above type of cases with a Priority of "Noted". In addition, we now have another person (the manager) setting the category and priority for these type of cases. They go to him first. He also sets the Milestone.

I appreciate any guidance you can give on the subject.

Thanks.

Answer 1

We have modified our workflow so that the default values for cases in most projects put them in a pool that means "unclassified" i.e. Assigned To a virtual user with Milestone of Not Determined and a Priority of 7 - not discussed yet. They are not forced defaults; the tester can change any of them. So, for critical Cases, or Cases that obviously fit in the current development cycle, they can be given the correct values and addressed by a developer immediately. For the other Cases, a product or team manager or a triage team has to review the unclassified Cases - prioritize them, set the milestone, assign them, etc.

I know in other shops the defaults are set to high, hoping that will ensure they don't fall thought the cracks. My view is that 100 Must Fixes that you don't properly address are just a bad as 100 not discussed yets. The important parts of the process are: educating the people who enter the Cases, so they know the value they assign in each field has meaning and is important; clearly define what those field values mean (as you have started doing - e.g. "we use Priority: Noted for these kinds of Cases); and setting up a process to properly deal with the cases that fall into the unclassified pool.