We're trying to come up with terms that better describe our bugs/defects. To us, the term 'bug' or 'defect' is too generic and doesn't accurately reflect what is happening. For example, instead of saying that there is a bug (in the general sense), we'd rather say what type of bug (an error, or enhancement, or improvement, etc.). What names do you use for describing 'bugs'?
We found http://www.softwaredevelopment.ca/bugs.shtml which has some pretty good classifications. How do you classify them?
We classify them as
When designing the classification for our bugtracker, I tried to be very conscious of the purpose of each field. Here's what we ended up with.
This field records the results of our planning. It's very useful to search and filter on: when a developer is out of tasks (everything assigned to him is done, or his work is blocked for any reason) he can just grab an issue from the list of all unassigned bugs sorted by "When":
We frequently move issues between "Now" and "Next", and review the "Soon" tasks from time to time and after a release. Occasionally we go through the "Later" tasks. "If ever" is the field we use instead of closing requests we aren't sure we're ever going to work on.
This field is our best estimate of how long the work is likely to take. It is notoriously hard to have an idea of this, but due to the logarithmic scale and order-of-magnitude roughness we are rarely off by more than one entry in this list:
This field is used in several circumstances. First and foremost, it is a major consideration as to what goes into the "When" field discussed above. I like using this field to pick a very short task to start with on a Monday if I'm not feeling too motivated. It's also useful to find work for a new employee or someone else who's not feeling motivated.
This field is for whoever does the project planning; developers don't really care. It helps record how much we think this work matters to our project's success:
It's used along with "How long will this take" to decide when we're going to work on this task.
This field is used for workflow. Every state shown below is either an "open" or a "closed" state. The bugtracker has shortcuts for showing only open bugs, and that's the main use for this field.
The subdivision into open/closed is the main purpose of this field, however each individual "closed" entry acts to summarise the outcome. This can often be inferred from comments too, but it helps to have a standard place where this information can be found.
There is a bugtracker-enforced rule that a Duplicate bug must have at least one link to say what the bug is a duplicate of.
We're quite explicit about not using an "in progress" state because from past experience, it's very hard to keep this properly up-to-date, and as a result the state can do more harm than good.
This is the closest to the conventional "bug type" field. Its main purpose is to describe the entry to a human. We almost never search or filter on this field. It's only there to save words in the bug title. The list varies somewhat from project to project, but here's a representative example:
Picking a value for all of the above is not always easy, so we allow the person entering the bug to leave empty any fields they can't figure out right now. We maintain the attitude that this is perfectly fine, even if you're just feeling lazy, because otherwise we might end up with garbage in these.
The fields "When" and "Importance" are often left blank because these things are for the project planner to decide. Entries with blank "Much work" get reviewed from time to time, with potential assignees asked to estimate it.
While large projects use all of the above, certain small projects do away with fewer. If they have no use for "Importance", we insist that the field is deleted from that project. The idea is that only fields that are being actively used should be present.
P.S. The above screenshots are of YouTrack, which I really rather like. It had no problem with us getting rid of all the built-in fields and using our own.
Code Complete's "Developer Testing" section classifies defects as:
(this is originally from a 1990 Beizer study)
Of course, the defect's class may only be evident with hindsight of it being fixed!
This classification scheme keeps the type of the defect distinct from its severity (serious -> insignificant) and priority (I need it yesterday -> pipe dream).
Also, this assumes the ticket has already been classified as a DEFECT, rather than an ENHANCEMENT or TASK (which are very standard types of ticket).
Something like orthogonal defect classification might be useful. The idea is to have a series of options such that each one only has a single possible value that makes sense for any and every submission. IBM Research has a few web pages devoted to the concept.
As far as types of defects, the only thing that I really want to know is if it's a defect or if it's an enhancement. A defect exists in a work product that doesn't conform to the artifact that generated it. For example, a requirement that doesn't adequately capture the intention of the stakeholder is defective. Similarly, a design that doesn't address a requirement or an implementation that doesn't realize a design or a requirement is defective. An enhancement or change request would be a modification to an artifact that otherwise meets the specified requirements. This could be a new requirement or a refactoring to reduce technical debt, as examples.
I believe that any comprehensive classification scheme would address the following questions. What you actually need to capture varies based on how you are using the data - using defect data to track tasks needs to be less complete than defect data that is an input into a rigorous metrics program.
Most of these, except for the reason for existing, apply equally to defects and enhancements.
Before you go about trying to reinvent the wheel (or the English language), shouldn't the emphasis be on the bug description?
'Bug' = not good / unwanted / mistake / error
Yes, it's generic, but you won't gain anything from making up new words to describe something bad.
I wouldn't call an enhancement or an improvement a bug at all.
I generally classify issues in an issue tracker like so:
Priority is generally a different issue altogether. Bugs can be anything from low priority to immediate, same with features, wishes and todos are generally always low.
I classify them as:
More granular classifications might be useful as an empircal study in bug taxonomy or for statistical analysis of some sort, but for practical purposes it only matters if they're fixed or not, can be reproduced or not, or are really bugs or not.
More than that, and I suspect you're playing with your food instead of eating it.
