Defect Management

Defect Logging:

Finding and fixing defects is an essential part of software development. Defects can be detected and reported by testers and end-users in all phases of the testing process. This article explains the defect life cycle, defect reporting and tracking, and defect analysis methods in detail.

Overview of the defect Management: 

Defect Management is defined as the process of recognizing, investigating, acting and disposing of defects. It involves recording defects, classifying them, and identifying the impact.

Managing defects is all about

1. Identification
2. Investigation
3. Analyzing
4. Logging
5. Tracking
6. Predicting

What is meant by defect?

A mismatch in the application and its specification is a defect. A human being can make an error (mistake), which produces a defect (fault, defect) in the code, in software or a system, or in a document. If a defect in code is executed, the system will fail to do what it should do (or do something it shouldn’t), causing a failure. Defects in software, systems or documents may result in failures, but not all defects do so.

Let us see different types of defects in software testing.

Testing defects are of two types:

–  Application Defect

–  Testing process defect

Application Defects:

Root cause analysis is not done by Testers. Developers do the root cause analysis of application defects.

Testers will do root cause analysis on the application defects detected in (defect leakage) UAT/production. This is to find why testers in SIT missed to identify the defects.

Also, Testers do root cause analysis on the rejected defects to identify the root cause of rejected defects in the project.

From the root cause analysis, a solution must be identified and implemented in the project to prevent the similar defects in future.

There are various root causes for the occurrence on defects and rejected Application Defects. They are as follows:

1. Test Execution
2. Inadequate Test Cases / Coverage
3. Nonconformance to standards
4. Incorrect /Missing Test Cases
5. Documentation/Typo Error
6. Automation Error
7. Build Issue
8. Exception/Error handling
9. Environment Issue
10. System Testing
11. Inadequate Test data
12. Inadequate Test Execution Coverage
13. Environment Issue

Defect causes can also be classified into:

1. Defect Cause
2. Omission
3. Lack of Knowledge
4. Miscommunication
5. Accidental

Testing process defect: 

Defects that are related to testing activities such as review defects found in testing artifacts are termed as testing process defects.

It is the responsibility of the test lead to identify the Root Cause Analysis of these Review defects in each Testing artifact. Based on the Root cause analysis a Defect Prevention Plan needs to be identified and implemented in the project. This will prevent these types of defects to be logged in future.

We have various types and causes for the review defects in a project.

Various Types of review defects are as follows:

1. Test Requirements
2. Incorrect Functionality
3. Missing Functionality
4. Nonconformance to standards
5. Documentation/Typo Error
6. Test Design
7. Inadequate Test Data
8. Inadequate Test Cases / Coverage
9. Documentation/Typo Error
10. Automation Script Error

Review Defects Root cause analysis is explained in detail in the later part of the session.

Defect causes can also be classified into:

1. Defect Cause
2. Omission
3. Lack of Knowledge
4. Miscommunication
5. Accidental

Sample Defect Life cycle

This diagram explains in detail the defect life cycle.

Defect Status is New when the new defect is raised

If a defect is found invalid, the status is changed to Rejected or the decision for the need to fix the defect in this release is taken

If the defect can be fixed in later releases, it is deferred. Otherwise, the status is changed to Open and is assigned to a developer

Dev. team fixes the defect and changes the status to Fixed.

The testing team retests the fix provided by the dev. Team. The status of the defect is changed to Closed if the application behaves as desired.

Otherwise, the status is changed to “Re-Open” and is assigned back to the developer. The developer will fix the defect and send to testing team for retesting.

Logging Defects

Any defect tracking tool selected should support the recording and communication of all significant information about the defect. For example, a defect log could include:

1. Defect ID number
2. Descriptive defect name and type
3. Source of defect – test case or other source
4. Defect severity
5. Defect priority

Defect status (e.g. open, fixed, closed, user error, design, and so on) – more robust tools provide a status history for the defect

Date and time tracking for either the most recent status change or for each change in the status history

Detailed description, including the steps necessary to reproduce the defect Component or program where defect was found

Screen shots, logs, etc. that will aid the developer in resolution process

Stage of origination

People assigned to research and / or correct the defect all the defect parameters, Defect type and typical causes at each phase.

The key point in defect logging is providing the development staff with as much information as necessary to reproduce the defect.  This can be broken down into 5 points:

1. Give a brief description of the problem

2. List the steps that are needed to reproduce the defect or problem

3. Supply all relevant information such as version, project and data used.

i) Attach the screen shots if possible to give more clarity.

4. Supply a copy of all relevant reports and data including copies of the expected results.

5. Summarize what you think the problem is.

1. Define Defect Name that is very easy for identification which helps to avoid duplication
2. Before Logging the Defect ensure it can be reproduced later.
3. Be Specific
4. Fill in all the parameters with relevant data
5. Defect Summary need to be given with clear scenario
6. Enter Defect Description in detail. It should cover with

Pre-requisite steps (Need to be given if the test case is not mapped)

Reproduce Steps (provide the test data)

Expected Result

Actual Result

Map Test Case ID

7. Attach Screenshot if necessary

8. Give Defect type as Coding error, Design error, New suggestion, Documentation issue, Hardware problem.

9. Do not use unprofessional language.

When you are logging a defect the more information you supply, the easier it will be for the developers to determine the problem and fix it.