Why is defect management process important in software development teams?

Anything that is wrong with the application, whether it is something that causes the application to crash or just a minor spelling mistake, is considered a defect.  When the application does not meet the requirements, or it does not perform as expected by the customer, it has defects.  When the application does not look good to the customer, or it does not ‘feel’ right, it has defects.

Defects are not always coding mistakes done by the developers.  Most defects are, but not all.  Defects can come from any stage in the software development cycle, because every stage involves people

Ques: What are the fields in a bug report?

This is ideally the lifecycle a defect goes through

•       New: When a defect is logged and posted for the first time. It’s state is given as new.

• Assigned: After the tester has posted the bug, the lead of the tester approves that the bug is genuine and he assigns the bug to corresponding developer and the developer team. It’s state given as assigned.

• Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.

• Retest: At this stage the tester do the retesting of the changed code which developer has given to him to check whether the defect got fixed or not.

• Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “closed”. This state means that the bug is fixed, tested and approved.

• Reopen: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “Assigned”. The bug goes through the life cycle once again.

• Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time

Why do defects have priority and severity?

1)  Severity:

It is the extent to which the defect can affect the software. In other words it defines the impact that a given defect has on the system. For example: If an application or web page crashes when a remote link is clicked, in this case clicking the remote link by an user is rare but the impact of  application crashing is severe. So the severity is high but priority is low.

Severity can be of following types:

·        Critical: The defect that results in the termination of the complete system or one or more component of the system and causes extensive corruption of the data. The failed function is unusable and there is no acceptable alternative method to achieve the required results then the severity will be stated as critical.

·        Major: The defect that results in the termination of the complete system or one or more component of the system and causes extensive corruption of the data. The failed function is unusable but there exists an acceptable alternative method to achieve the required results then the severity will be stated as major.

·        Moderate: The defect that does not result in the termination, but causes the system to produce incorrect, incomplete or inconsistent results then the severity will be stated as moderate.

·        Minor: The defect that does not result in the termination and does not damage the usability of the system and the desired results can be easily obtained by working around the defects then the severity is stated as minor.

·        Cosmetic: The defect that is related to the enhancement of the system where the changes are related to the look and field of the application then the severity is stated as cosmetic.

2)  Priority:

Priority defines the order in which we should resolve a defect. Should   we fix it now, or can it wait? This priority status is set by the tester to the developer mentioning the time frame to fix the defect. If high priority is mentioned then the developer has to fix it at the earliest. The priority status is set based on the customer requirements. For example: If the company name is misspelled in the home page of the website, then the priority is high and severity is low to fix it.

Priority can be of following types:

·        Low: The defect is an irritant which should be repaired, but repair can be deferred until after more serious defect have been fixed.

·        Medium: The defect should be resolved in the normal course of development activities. It can wait until a new build or version is created.

·        High: The defect must be resolved as soon as possible because the defect is affecting the application or the product severely. The system cannot be used until the  repair has been done.

When does a defect gets deferred?

·        I know of two definitions for a Deferred bug

1) Most Common: A defect that is confirmed by the team to be a bug but the effort to correct it at this time exceeds the ROI (Return On Investment). This can often be the case when a re-design is scheduled for that area of the application, or if technology barriers exist that make correction of the bug prohibitive.

2) Least Common:
a) A defect that has been detected early in the development process before the code is ready to submit to QA for formal test.
b) A defect that has been submitted by the QA group that covers behaviors not well defined by requirements documentation. These bugs may remain in a deferred state awaiting furthor review by all interested team parties

Ques: How do you deal with an inconsistent defect?

·        A bug which is not reproducible when retesting the same in the same version of the application i.e. the defect is valid but it’s not reproducible always. This case better to attach screenshots and clear steps to reproduce with test data while logging the defect to avoid unnecessary comments by other teams.Its nothing but a Non-Reproducible Bug.

Ques: How do you deal with an inconsistent defect?

·        Defect logging, a process of finding defects in the application under test or product by testing or recording feedback from customers and making new versions of the product that fix the defects or the clients feedback.

Defect tracking is an important process in software engineering as Complex and business critical systems have hundreds of defects. One of the challenging factors is Managing, evaluating and prioritizing these defects. The number of defects gets multiplied over a period of time and to effectively manage them, defect tracking system is used to make the job easier.

Examples – Hp Quality Center, IBM Rational Quality Manager

Defect Tracking Parameters

Defects are tracked based on various parameters such as:

·        Defect Id

·        Priority

·        Severity

·        Created by

·        Created Date

·        Assigned to

·        Resolved Date

·        Resolved By

·        Status