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?

  • 2
    What problem are you trying to solve ?
    – Jim Rush
    Commented Feb 16, 2011 at 1:34
  • Bugs are bugs. Enhancements or improvements are something else.
    – Marcie
    Commented Feb 17, 2011 at 20:27

7 Answers 7


We classify them as

  • change-request (small enhancements, change of behavior)
  • design-change-request (big features that require a design document)
  • sw-bug (software bug due to error of programmer)
  • test-bug (not really a software bug, tester's mistake in his script)
  • support-request (information/clarification request, usually from the field)
  • invalid (the reported issue doesn't exist or is the expected behavior)
  • duplicate (exact same issue was already reported)
  • doc-bug (documentation error, documentation need to be updated with correct behavior) (Thanks to Michael for pointing this one)
  • we use the same kind of classification (abeit with different label). The only thing we have is a dt-bug (software bug due to incorrect values in parametrisation table). We're working on ERP and a lot of process depends on definitions stored in tables. Commented Feb 16, 2011 at 14:20
  • I like this list, but where's the one for missing or incorrect information in the documentation? Sounds like it almost fits in support-request. Commented Feb 16, 2011 at 14:27
  • @Michael I forgot to add that one. We call that a doc-bug. Will edit answer to add this one too. @PATRY I guess there are always domain specific categories. We are in the embedded domain and do not use any databases. So we don't have one.
    – aufather
    Commented Feb 16, 2011 at 14:37

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.

When are we going to work on it?

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":

enter image description here

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.

How long is this going to take to fix?

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:

enter image description here

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.

How important is this task, in the grand scheme of things?

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:

enter image description here

It's used along with "How long will this take" to decide when we're going to work on this task.

What's the bug's state?

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.

enter image description here

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.

What is this bug about?

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:

enter image description here

Empty fields

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.

  • We divide importance into two categories, "Delivery Impact" basically would we be able to "go live" with this bug and its workarounds, and, "Testing/Development Impact" how much the bug affects further testing and development. The second class tends to get a higher priority. Commented Oct 8, 2012 at 11:35

Code Complete's "Developer Testing" section classifies defects as:

  • Structural
  • Data
  • Functionality as Implemented
  • Construction
  • Integration
  • Functional requirements
  • Test definition or execution
  • System, software architecture
  • Unspecified

(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.

  • Is this a problem in an existing work product or an enhancement to a work product? Either something, whether it's a requirement, a document, or a code module, doesn't conform to specifications or the specifications upon which the work products are based must be enhanced.
  • What work product is affected? Does this affect a document (and which one)? Is it against code? Unit tests? Depending on your release process, it might also address which version(s) are affected by this defect or enhancement as an additional data element.
  • What is the priority and/or severity of this defect? Priority is generally a customer or user-defined element that addresses how quickly they need a resolution of some kind. Defects of higher priority need to be addressed first. Note that "addressed" might simply mean analyzing and developing a work-around until a defect can be adequately resolved. Severity typically defines how work is impacted - low severity means that it has a minimal impact on the business value, while a higher severity means that the users are having extreme difficulty accomplishing their business objectives because of the defect.
  • When was the defect reported? When was it finally resolved? This can be used to track time-to-closure data, which might be related to customer satisfaction metrics.
  • Where was the defect found and where was it originally injected? This is really only required if you're capturing defect containment metrics, such as total defect containment (the number of defects found/fixed in house versus post-release) or phase containment effectiveness. I prefer an activity-based concept (something along the lines of requirements, architecture/design, implementation, testing, field), neglecting iterations, so that I can determine which activities are associated with processes that are proficient at capturing defects and where I need to improve my processes.
  • What caused this defect to exist or be injected? How you define this depends on your organization, but the PSP gives a good starting point. You don't want anything too complicated such that it can't be understood, and in line with Orthogonal Defect Classification, don't want defects to be able to be put into multiple categories.
  • How can I identify and refer to this defect? Typically, a unique identifier and a short, human-readable title provide this information. These can be used to provide information to customers/users about work-in-progress and in status reports or commit logs to help track defects to closure.

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:

  • Bug - A problem in the code leading to unexpected output.
  • Support - Something that needs to be done before other issues can be looked at. ie. a bug that the CSV generator is generating errors is because there is no proper CSV generator yet. Support - write a CSV generator.
  • Feature - An enhancement or improvement I'd like to make. Can be big or small.
  • Wish - A real eye-in-the-sky type feature that will probably never see the light of day - 'wouldn't it be great if the software could read your mind and direct you to what you were looking for automatically!?'
  • Todo - Something that requires investigation/scoping before it can be properly detailed/classified.

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:

  • open
  • fixed
  • can reproduce, not fixed yet
  • unable to reproduce
  • enhancement/not bug
  • feature/intentional

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.

sequence diagram for bug statuses

  • We use similar classification as the state of the bug. Not the type. The state can be open (new item), assigned (by manager or engineer), under-development (engineer), fixed (engineer), verified (originator or tester), cannot-reproduce (engineer), watch (tester is not sure of the fix, but it doesn't seem to happen), postponed (will take up later). The classification of issues are important, for example, for a customization project, change-requests are billed, while bugs aren't. Design-change-requests should have design document as per ISO process.
    – aufather
    Commented Feb 16, 2011 at 14:56
  • @aufather: i think you missed the point - describing bugs does not fix them, anymore than describing a seed makes it grow. This is navel-gazing. [and 'type' is the OP's terminology; i agree it is really the state] Commented Feb 16, 2011 at 16:53
  • These are states of a bug, not classifications. A classification should not change, but a state can.
    – Jay Elston
    Commented Jun 7, 2011 at 16:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.