0% found this document useful (0 votes)
16 views4 pages

Defect Cycle

The document discusses the Software Development Life Cycle (SDLC) and the importance of identifying and resolving defects or bugs during software development. It outlines the Defect Life Cycle, detailing the various states a defect goes through from identification to closure, emphasizing the need for effective management to ensure high-quality software. Additionally, it highlights the limitations of the defect management process, including being time-consuming and resource-intensive.

Uploaded by

abhishek979118
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
16 views4 pages

Defect Cycle

The document discusses the Software Development Life Cycle (SDLC) and the importance of identifying and resolving defects or bugs during software development. It outlines the Defect Life Cycle, detailing the various states a defect goes through from identification to closure, emphasizing the need for effective management to ensure high-quality software. Additionally, it highlights the limitations of the defect management process, including being time-consuming and resource-intensive.

Uploaded by

abhishek979118
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

As we know during the development of any software product the

development teams follow the Software Development Life Cycle (SDLC)


processes. But the development process is not so easy and always runs
smoothly. During the development process when a product is being
developed different types of defects or bugs arise with the product. So these
defects are identified and resolved throughout the development process just
to deliver a good quality software product at last. So in this article, we will
discuss these bugs in the software development process how these are
identified during software testing, and how these are resolved.

What is a Bug/Defect?

A defect is an error or bug in an application that is created during the


building or designing of software due to which software starts to show
abnormal behaviors during its use. So it is one of the important
responsibilities of the tester to find as many as defects possible to ensure the
quality of the product is not affected and the end product is fulfilling all
requirements perfectly for which it has been designed and provides the
required services to the end-user. Because as much as defects will be
identified and resolved then the software will behave perfectly as per
expectation.

What is the Defect Life Cycle?

In the Software Development Process, the Defect Life Cycle or bug that it
goes through covering a specific set of states in its entire life. Mainly bug life
cycle refers to its entire state starting from a new defect detected to the
closing off of that defect by the tester.

 The journey of the Defect Cycle varies from organization to


organization and also from project to project because development
procedures and platforms as well as testing methods and testing tools
differ depending upon organizations and projects.

 The number of states that a defect goes through also varies depending
upon the different tools used and processes followed during
the software testing.

 The objective of the defect lifecycle is to easily coordinate and


communicate the current status of the defect and thus help to make
the defect-fixing process efficient.
 New: When any new defect is identified by the tester, it falls
in the ‘New’ state. It is the first state of the Bug Life Cycle.
The tester provides a proper Defect document to the
Development team so that the development team can refer to
Defect Document and can fix the bug accordingly.
 2. Assigned: Defects that are in the status of ‘New’ will be
approved and that newly identified defect is assigned to the
development team for working on the defect and to resolve
that. When the defect is assigned to the developer team the
status of the bug changes to the ‘Assigned’ state.
 3. Open: In this ‘Open’ state the defect is being addressed by
the developer team and the developer team works on the
defect for fixing the bug. Based on some specific reason if the
developer team feels that the defect is not appropriate then it
is transferred to either the ‘Rejected’ or ‘Deferred’ state.
 4. Fixed: After necessary changes of codes or after fixing
identified bug developer team marks the state as ‘Fixed’.
 5. Pending Request: During the fixing of the defect is
completed, the developer team passes the new code to the
testing team for retesting. And the code/application is pending
for retesting on the Tester side so the status is assigned as
‘Pending Retest’.
 6. Retest: At this stage, the tester starts work of retesting
the defect to check whether the defect is fixed by the
developer or not, and the status is marked as ‘Retesting’.
 7. Reopen: After ‘Retesting’ if the tester team found that the
bug continues like previously even after the developer team
has fixed the bug, then the status of the bug is again changed
to ‘Reopened’. Once again bug goes to the ‘Open’ state and
goes through the life cycle again. This means it goes for Re-
fixing by the developer team.
 8. Verified: The tester re-tests the bug after it got fixed by
the developer team and if the tester does not find any kind of
defect/bug then the bug is fixed and the status assigned is
‘Verified’.
 9. Closed: It is the final state of the Defect Cycle, after fixing
the defect by the developer team when testing found that the
bug has been resolved and it does not persist then they mark
the defect as a ‘Closed’ state.

Few More States that also come under this Defect Life Cycle:

1. Rejected: If the developer team rejects a defect if they feel that defect is
not considered a genuine defect, and then they mark the status as
‘Rejected’. The cause of rejection may be any of these three i.e Duplicate
Defect, NOT a Defect.

2. Deferred: If the developer team feels that the defect that is identified is
not a prime priority and it can get fixed in further updates or releases then
the developer team can mark the status as ‘Deferred’. This means from the
current defect life cycle it will be terminated.

3. Duplicate: Sometimes it may happen that the defect is repeated twice


or the defect is the same as any other defect then it is marked as a
‘Duplicate’ state and then the defect is ‘Rejected’.

4. Not a Defect: If the defect has no impact or effect on other functions of


the software then it is marked as ‘NOT A DEFECT’ state and ‘Rejected’.

6. Can’t be Fixed: If the developer team fails to fix the defect due to
Technology support, the Cost of fixing a bug is more, lack of required skill, or
due to any other reasons then the developer team marks the defect as in
‘Can’t be fixed’ state.

7. Need more information: This state is very close to the ‘Non-


reproducible’ state. But it is different from that. When the developer team
fails to reproduce the defect due to the steps/document provided by the
tester being insufficient or the Defect Document is not so clear to reproduce
the defect then the developer team can change the status to “Need more
information’. When the Tester team provides a good defect document the
developer team proceeds to fix the bug.

Conclusion

The bug life cycle is a crucial process in software development that ensures
high-quality products by systematically identifying, tracking, and resolving
defects. While it can be time-consuming and resource-intensive, the benefits
of early issue detection, improved communication, and enhanced customer
satisfaction outweigh the challenges. By effectively managing the bug life
cycle, development teams can reduce costs, improve ROI, and deliver
reliable, user-friendly software.

Limitation

Time consuming:- especially in larger or complex projects.

Resource intensive:- it requires significant human, technological and financial


resources. This limitation affects projects timelines, budgets and team
productivity.

You might also like