Role of Defect

Table of contents

Reading Time: 4 minutes

Fighting Defect Clusters in Software Testing - TestRail Blog

Happy Winter’s, readersss! today i came here for writing about coming topic which is Defect Life cycle.

Introduction

DEFECT

It is the process of identifying defects, where a defect is any difference between actual and expected results.

BUG

If QA find any mismatch in the application/system in testing phase then we call it as BUG. (Ringing Alarm)

ERROR

If a developer is unable to successfully compile or run program then we call it as an ERROR.

FAILURE

Once the product is deployed to the customer and they finds any issue then they called the product as a failure product but if an end user find an issue then that particular issue will take as FAILURE.

Let consider, what will take place if the testing team identify the defects verbally and the development team renovates the status of the defect verbally? In those circumstance, no’s of defect starts increasing in the project and circumstances will soon be very worst but to handle those circumstance. We have two Authorities Project Manager and Tech BA to draw water from well.

Defect Management Process (DMP)

The process of finding defects and reducing them at the lowest cost is take as Defect Management Process.

1) Defect Prevention:

Defect Prevention is one of the important activities in any software project. It is QA process to identify the root cause of defect and improve the process to avoid introducing defects, which help to improve the quality of the software product. Defect Prevention is the process of improving quality and productivity by preventing the injection of defects into a software work product.

However, it is not possible to eliminate all the defects but at least you can reduce the footprint of the defect and cost to settle the same.

Major steps involved in Defect Prevention are:-

Identify Critical Risk
Estimate Expected Impact
Minimize Expected Impact

2) Deliverable Baseline:

Deliverables are considered to be ready for further development i.e. the deliverables meet exit criteria. When a deliverable is base lined, any further changes are controlled. Error in a deliverables are not considered defect until after the deliverables is base lined.

3) Defect Discovery:

It is impractical to pull out all the defects from the system and build a system as a defect-free one. But you can evaluate the defects early before they are befittingly expensive to the project. We can say that the defect find means it is befittingly obtain to the attention of the development team and after an audit of that, the defect development team also received it as a defect.

Major steps involved in Defect Discovery:-

Find a Defect
Report a Defect
Acknowledge a Defect

4) Defect Resolution:

In the above process, the testing team has recognized the defect and outlined it to the development team. Now here the development team needs to progress for the solution of the defect.

Major steps involved in Defect Resolution:-

Prioritize the Risk
Report the Resolution
Fix the Defect

5) Process Improvement:

To identify the ways to improve the process to prevent further occurrences of similar defects i.e. corrective and preventive action is taken for processes improvement.

For process improvement, everybody in the project need to look back and check from where the defect was originated. Based on that you can make a change in the validation process, base-lining document, review process which may seize the defects early in the process which are less costly.

The below defect life cycle covers all attainable status:

NEW

When QA finds a newly bug then status of defect will take as NEW.
QA shares proper documents of related defect to the developer to reproduce and resolve the defect together.
Those defects which are in the status of new will approved by Project manager, Tech BA, Module lead if valid and assigned to the development team.

ASSIGNED

When defect is assign to the development team then the status of the defect changes to ASSIGNED.

OPEN

When the development team is accept the bug then the status of the defect will take as OPEN.
If the status is open, Means that the development team is analysing and work to fix the defect.

FIXED

When developer done the necessary code changes and verified the changes, then the status will be changed as FIXED and bug is passed to the testing team.

TEST

When the defect is fix and it is ready to test by QA then the status of defect will take as TEST.

VERIFIED

While doing test in the software, If there is no defect then the status changes to VERIFIED.

CLOSED

After checking the defect, If there is no bug in the software then the status of the defect changes to CLOSED.

REOPENED

If the bug still exist even after the bug is fix by the developer, the tester will change the status to REOPENED.

DUPLICATE

If the bug is repeated twice or the defect corresponds the same concept of bug, the status of defect changes to DUPLICATE.

DEFERRED

In some cases the status will take as DEFERRED.

Bug found during end of release and it is minor or not important to fix it immediatedly.
If the bug is not related to current build.
Customer is thinking to change the requirement.