Ways to resolve a defect

How often we are waiting for a fix for that defect we found at the last minute? Everybody is stressed and the blaming game started immediately. So, the spotlight is put on to testers quickly as they are the show stopper. Why don't they found that defect earlier? I am not going to discuss that blaming game here. Instead, let's have a look at the feasible ways to resolve a defect and meet the deadline.

When a defect is found, it is far too often that we jump to the conclusion that it needs to be fixed before the software to be released. However, is it true that there is only one option in resolving a defect?

Theoretically, there are unlimited ways to resolve a defect. However, they can be summarized into the following 4 options:

1. Fix the defect in the current release;
2. Fix the defect in a future release;
3. Patch the defect in the current release and fix it in a future release;
4. Accept the defect as a limitation of the system.

By accepting a defect as a limitation of the system, it means that the defect does not justify a fix. In other words, the defect does not worth to be fixed at all. However, workaround may be required for this option to keep the system going.

What is a "Bug"?

Very often, defect in software is also called "bug".

Based on Wikipedia, the invention of the term "bug" is attributed to Grace Hopper who had publicized in 1947 the cause of a malfunction in an early computer to a moth that trapped in the machine. The moth had been removed carefully and tapped to a log book with the notation "First actual case of bug being found". Although Grace Hopper or the person who find the insect might not have coined the term "bug", it has been suggested that they had coined the related term "debug". Since then, defects or errors in software become known as bug".

What are the types of Issue?

As explained in a separate posting, issue is a subject or problem which people are thinking and/or talking about a software product or project.

Based on this interpretation, what could be an issue? While the possibilities could be endless, the following are a few common examples in relation to software development.

1. Raised by customers

• Fault report of a product;
• Service request for a product;
• Change request to a product.

2. Raised by production support

• Problem found in a product;
• Change request to a product.

3. Raised by developer/test analyst

• Change request to a product;
• Defect found in a product;
• Deficiency in a product.

4. Raised by project manager

• Risk to deliver a project.

Based on the above, we could comfortably summarize issues into the following categories or types.

1. Fault report of a product;
2. Problem in a product;
3. Defect in a product;
4. Deficiency in a product;
5. Change request to a product;
6. Service request for a product;
7. Risk to a project.

What is an Issue?

There are different interpretation of an "Issue" to different people or organizations. Some people may view an issue the same as a "problem", "defect" or "error". However, what exactly is an "Issue"?

Let's go back to the basics and look at the meaning of the word "Issue". According to online Cambridge Advanced Learner's Dictionary, issue is,

A subject or problem which people are thinking and talking about.

In the context of a software development, issue could be anything that people are thinking and talking about in relation to the project. This gives us a very good idea on what an issue is. That is,

A subject or problem which people are thinking and/or talking about a software product or project.

This interpretation is general but should be adequate to cover what most of us perceived as an issue.

What is a Defect?

There may be a number of definitions of defect. However, there is a common interpretation among the dictionaries.

A lack of something necessary or desirable for completeness, adequacy or perfection.

When it comes to manufacturing, what is necessary to a product is usually documented into product specifications. Besides, what is desired by product users can be interpreted as user expectations. Therefore, defect can be translated into the following definition.

Non-conformance of a product with the specified requirements, or non-fulfillment of user expectations.

As we can see from these definitions, defect is closely associated with the actual behaviour or features of a product and its user expectations. Therefore, we could safely interpreted defect as:

The deviation of actual from expected behaviour or features of a product.