Bug, er Defect Terminology

Question

As the BigCo I worked for got serious about software development, they encouraged more formal terminology. Instead of bugs, which might randomly just happen, they preferred the term defect which could be prevented. Tongue firmly in cheek, I developed the following guideline:

Levels of Unexpected Software Events (USE)

An Unverified Feature Observation (UFO) is a term that describes an observation of software behavior that has been reported to the development team, but not yet verified. Once verified, the following list describes the event.

• Enhancement: A USE which provides a definite benefit to the customer
• Feature: A USE that is designed to work that way, regardless of the benefit. Note the contradiction. "It's not a bug, it's a feature!"
• Occurence: A relatively neutral USE in terms of its benefits and drawbacks.
• Anomaly: For this use, it is unclear about its potential impact
• Millibug: A USE that the development team agrees has some minor drawbacks
• Bug: A USE with drawbacks
• Megabug: Don't even THINK this term.

What terminology do you use for bugs, er defects, both serious and not?

Answer 1

Eric Lippert has a great blog post on this - categorising defects as vexing, boneheaded, or fatal.

Answer 2

Usually where I work we use:

• Improvement. This category is not a bug, it's just a recommendation, maybe the tester thinks the software should work in a different way or that a certain feature would be interesting. It doesn't violate any requirement and so its implementation is not mandatory.
• Cosmetical. This category groups cosmetical errors such as mispelling, translation errors, missalignment, etc
• Minor. This is a bug, it's category is minor which means it doesn't affect the usual work with the application but it's still an error.
• Major. This is a major bug, it blocks the execution of given requirement but a workaround exits to carry out that requirement (that is, the operation can be made in another way)
• Critical. Same as major but not workaround exits or a critical issue is filled if there's a requirement missing.
• Blocking. A blocking bug is the kind of bugs that keeps you from being able to run the application (application crashes when doing common operations, big memory leaks, etc)

For every category there are guidelines to precisely identify it category. This protects both your client and you and contracts can be stablished to account for the quality of the product. For example, for a given delivery there must be no blocking or critical issues and a given number of major issues (and for example 20 minor make 1 mayor). On the same way, if the user reports an issue then it can be categorized as the user and you agree on the category it belongs (a missing requirement is not Blocking but Critical, if a workaround exits then is just major and so on)

Answer 3

We currently are using a minimally modified version of MSF for Agile Software Development Projects with TFS. The following is from the MSDN Documenation:

• Bug. Represents a problem or potential problem in your application.
• Risk. Represents a possible event or condition that would have a negative impact on your project.
• Scenario. Represents a single path of user interaction through the system you are building.
• Task. Identifies a specific item of work for a team member to perform.
• Quality of Service Requirement. Represents a non-functional requirement such as a security, performance or manageability requirement.

We have already started to modify some of the fields related to the items to better fit our workflow and have added a "Code Review" item that can be created as a child of any of the work item type. And by "can be created", I mean "must be created" as we have a check-in policy requiring an approved code review prior to check-in.

On a personal level, I have always hated the term "bug" because it comes with a built-in negative connotation. Regardless of the workflow within a company and what they call a "bug", I always refer to it as a "defect".

Answer 4

Brain-Bug: This bug has sucked the brain out of a significant fraction of the development team while trying to verify, re-produce, analyze and/or fix it.

Answer 5

Defect.

Bug, though widely used implies that it is something that is cute and just happens. The fact is, that we need to call it what it is and use appropriate terminology. Defects are injected into the product.

The proliferation of defect tracking tools that have "bug" in the name do nothing to help this.

Answer 6

Term for not having any bugs: Zarro Boogs

Answer 7

Every development team that is about shipping a product needs to know Showstopper, best described in the book Show Stopper about shipping Windows NT. A Show Stopper is a problem serious enough that the software will not ship with that issue.

Answer 8

Defect. That is the formal term primarily because we use VersionOne which treats world as Stories (enhancements, new features) and defects (software not working as expected).

We informally use bugs. Tracker Items is another term used because that is what defects/bugs are called in another system used previously. Legacies!

Answer 9

Mistake.

Both "bug" and "defect" ignore the fact that a human caused the problem - bugs just happen, while defects can be in both workmanship (coding) and materials (hardware, libraries, environment, ...). "Defect" also suffers from the "corporate-suit-speak" connotation. "Mistake" highlights that the problem was caused by a developer, while avoiding a blunt assignment of blame, as something like "error" might do.

Answer 10

In BS 7925-1(Glossary) - Glossary of terms used in software testing: An error is defined as: “A human action that produces an incorrect result”. A defect is defined as: “A manifestation of an error in software”. A failure is defined as: “Deviation of the software from its expected delivery or service”.

With these definitions a causal chain can be seen: A person makes an error that creates a defect in the software that can cause a failure in operation.

The link of this chain that is reported is the defect present in software.

A defect is identified by a repeatable, identifiable failure of the system to perform in the manner specified and agreed during the detailed Requirement, Specification or Design phases of the project and as outlined in the User Requirement, Function Specification or Software Module Design documents.

A defect is only termed a defect once the failure it causes is proven to be:-
• Reproducible,
• Documented,
• Inconsistent with the approved specifications.

Irreproducible failures are classed as incidents.

In our company once defects are reported they are assigned a Severity (Showstopper, Major, Minor Cosmetic) and a Priority (Urgent, Very High, High, Medium, Low).