Defect/Bug Life Cycle in Software Testing

 

What is Defect Life Cycle?

Defect life cycle, also known as Bug Life cycle is the journey of a defect cycle, which a defect goes through during its lifetime. It varies from organization to organization and also from project to project as it is governed by the software testing process and also depends upon the tools used.

Defect Life Cycle - Workflow:

Defect Life Cycle in Software Testing

Defect Life Cycle States:

  • New - Potential defect that is raised and yet to be validated.

  • Assigned - Assigned against a development team to address it but not yet resolved.

  • Active - The Defect is being addressed by the developer and investigation is under progress. At this stage there are two possible outcomes; viz - Deferred or Rejected.

  • Test - The Defect is fixed and ready for testing.

  • Verified - The Defect that is retested and the test has been verified by QA.

  • Closed - The final state of the defect that can be closed after the QA retesting or can be closed if the defect is duplicate or considered as NOT a defect.

  • Reopened - When the defect is NOT fixed, QA reopens/reactivates the defect.

  • Deferred - When a defect cannot be addressed in that particular cycle it is deferred to future release.

  • Rejected - A defect can be rejected for any of the 3 reasons; viz - duplicate defect, NOT a Defect, Non Reproducible.

  • Defect Life Cycle In Detail

    The Defect Life Cycle, also known as the Bug Life Cycle, is a cycle of defects from which it goes through covering the different states in its entire life. This starts as soon as any new defect is found by a tester and comes to an end when a tester closes that defect assuring that it won’t get reproduced again.

    Defect Workflow

    It is now time to understand the actual workflow of a Defect Life Cycle with the help of a simple diagram as shown below.

    Defect Life cycle

    Defect States

    #1) New: This is the first state of a defect in the Defect Life Cycle. When any new defect is found, it falls in a ‘New’ state, and validations & testing are performed on this defect in the later stages of the Defect Life Cycle.

    #2) Assigned: In this stage, a newly created defect is assigned to the development team to work on the defect. This is assigned by the project lead or the manager of the testing team to a developer.

    #3) Open: Here, the developer starts the process of analyzing the defect and works on fixing it, if required.

    If the developer feels that the defect is not appropriate then it may get transferred to any of the below four states namely Duplicate, Deferred, Rejected, or Not a Bug-based upon a specific reason. We will discuss these four states in a while.

    #4) Fixed: When the developer finishes the task of fixing a defect by making the required changes then he can mark the status of the defect as “Fixed”.

    #5) Pending Retest: After fixing the defect, the developer assigns the defect to the tester to retest the defect at their end, and until the tester works on retesting the defect, the state of the defect remains in “Pending Retest”.

    #6) Retest: At this point, the tester starts the task of retesting the defect to verify if the defect is fixed accurately by the developer as per the requirements or not.

    #7) Reopen: If any issue persists in the defect, then it will be assigned to the developer again for testing and the status of the defect gets changed to ‘Reopen’.

    #8) Verified: If the tester does not find any issue in the defect after being assigned to the developer for retesting and he feels that if the defect has been fixed accurately then the status of the defect gets assigned to ‘Verified’.

    #9) Closed: When the defect does not exist any longer, then the tester changes the status of the defect to “Closed”.

    A Few More:

    • Rejected: If the defect is not considered a genuine defect by the developer then it is marked as “Rejected” by the developer.
    • Duplicate: If the developer finds the defect as same as any other defect or if the concept of the defect matches any other defect then the status of the defect is changed to ‘Duplicate’ by the developer.
    • Deferred: If the developer feels that the defect is not of very important priority and it can get fixed in the next releases or so in such a case, he can change the status of the defect as ‘Deferred’.
    • Not a Bug: If the defect does not have an impact on the functionality of the application, then the status of the defect gets changed to “Not a Bug”.

    The mandatory fields where a tester logs any new bug are Build version, Submit On, Product, Module, Severity, Synopsis and Description to Reproduce

    In the above list, you can add some optional fields if you are using a manual Bug submission template. These Optional Fields include Customer name, Browser, Operating system, File Attachments, and screenshots.

    The following fields remain either specified or blank:

    If you have the authority to add bug Status, Priority, and ‘Assigned to’ fields then you can specify these fields. Otherwise, the Test Manager will set the status and Bug priority and assign the bug to the respective module owner.

    Look at the following Defect cycle

    Defect/Bug Life cycle

    The above image is quite detailed and when you consider the significant steps in Bug Life Cycle you will get a quick idea about it.

    Upon successful logging, the bug was reviewed by the Development and Test manager. Test Managers can set the bug status as Open and can Assign the bug to the developer or the bug may be deferred until the next release.When a bug gets assigned to a developer, he/she can start working on it. The developer can set the bug status as won’t fix, Couldn’t reproduce, Need more information, or ‘Fixed’.

    If the bug status set by the developer is either “Need more info” or “Fixed” then the QA responds with a specific action. If the bug is fixed then the QA verifies the bug and can set the bug status as verified closed or Reopen.

    Guidelines for Implementing a Defect Life Cycle

    Some important guidelines can be adopted before starting to work with the Defect Life Cycle.

    They are as follows:

    • It is very important that before starting to work on the Defect Life Cycle, the whole team clearly understands the different states of a defect (discussed above).
    • Defect Life Cycle should be properly documented to avoid any confusion in the future.
    • Make sure that each individual who has been assigned any task related to the Defect Life Cycle should understand his/her responsibility very clearly for better results.
    • Each individual who is changing the status of a defect should be properly aware of that status and should provide enough details about the status and the reason for putting that status so that everyone who is working on that particular defect can understand the reason of such a status of a defect very easily.
    • The defect tracking tool should be handled with care to maintain consistency among the defects and thus, in the workflow of the Defect Life Cycle.

    Next, let’s discuss the interview questions based on the Defect Life Cycle.

    Frequently Asked Questions

    Q #1) What is a defect in the perspective of Software Testing?

    Answer: A defect is any kind of flaw or error in the application that is restricting the normal flow of an application by mismatching the expected behavior of an application with the actual one.

    Q #2) What is the major difference between Error, Defect, and Failure?

    Answer:

    Error: If the developers find that there is a mismatch in the actual and expected behavior of an application in the development phase then they call it an Error.

    Defect: If testers find a mismatch in the actual and expected behavior of an application in the testing phase then they call it a Defect.

    Failure: If customers or end-users find a mismatch in the actual and expected behavior of an application in the production phase then they call it a Failure.

    Q #3) What is the status of a defect when it is initially found?

    Answer: When a new defect is found, it is in a new state. This is the initial state of a newly found defect.

    Q #4) What are the different states of a defect in the defect life cycle when a defect is approved and fixed by a developer?

    Answer: Different states of a defect, in this case, are New, Assigned, Open, Fixed, Pending Retest, Retest, Verified, and Closed.

    Q #5) What happens if a tester still finds an issue in the defect that is fixed by a developer?

    Answer: The tester can mark the state of the defect as . Reopen if he still finds an issue with the fixed defect and the defect gets assigned to a developer for retesting.

    Q #6) What is a producible defect?

    Answer: A defect that is occurring repeatedly in every execution and whose steps can be captured in every execution, then such a defect is called a “producible” defect.

    Q #7) What type of defect is a non-reproductible defect?

    Answer: A defect that is not occurring repeatedly in every execution and is producing only at some instances and whose steps as proof have to be captured with the help of screenshots, then such a defect is called as a no reproducible.

    Q #8) What is a defect report?

    Answer: A defect report is a document that includes reporting information about the defect or flaw in the application which is causing the normal flow of an application to deviate from its expected behavior.

    Q #9) What details are included in the defect report?

    Answer: A defect report consists of Defect ID, Description of the defect, Feature Name, Test Case Name, Reproducible defect or not, Status of the defect, Severity, and Priority of the defect, Tester Name, Date of testing of the defect, Build Version in which the defect was found, the Developer to whom the defect has been assigned, name of the person who has fixed the defect, Screenshots of a defect depicting the flow of the steps, Fixing the date of a defect, and the person who has approved the defect.

    Q #10) When is a defect changed to a ‘deferred’ state in the defect life cycle?

    Answer: When a defect that is found is not of very high importance and the one which can get fixed in the later releases are moved to a ‘deferred’ state in the Defect Life Cycle.


Comments

Post a Comment

Popular posts from this blog

Resolving Exceptions for Early and Late Clock-Ins and Clock-Outs

Image
  The procedures for resolving many clocking-related exceptions are quite similar. This topic describes how to resolve a Clocked Out Early exception, but the same procedure can also be use to resolve the following exceptions: Clocked In Early exception Clocked In Late exception Clocked Out Late exception To resolve a Clocked Out Early exception: From the Time & Attendance menu, select  Home . Note:  If the Home option is not visible, make sure that you have selected  Manager  in the Role Selector. In the Exceptions column, click  Clocked Out Early . A new page will display a list of all of the time pairs in the selected pay period that have early clock-out times. Tip:  To view more detailed information about a time pair in the list, click the icon in the  Status  column. Review the actual recorded time and the scheduled time on each row and select the check box for the solution you want to apply to each time pair. The two solutions that a...
Read more

Exceptions on timecard and resolution

Image
Flagging exceptions, like Late In, Early Out, Unscheduled or Missing Punches assists managers in identifying potential issues with their employee’s timecards. Missing punches should be addressed before processing payroll. If there is no matching in and out punch, then the time span will not be processed for that time period. It also will help the manager identify recurring issues with their employees come to work at non scheduled times. Exceptions are flags or markers used to alert operators when employees work outside of their assigned shifts. They are used only as flags and perform no other function within Workforce Timekeeper. Exceptions track cases where an employee works “differently” from the expected work conditions, such as unscheduled, early, or late. How does Workforce Central know if you’re late or early to work? You have to have a schedule. Workforce Timekeeper reports abnormal employee activity such as early arriva...
Read more

Kronos Pay Code Descriptions

  Codes Requested by or on Behalf of an Employee, Not Entered Directly on the Time Card: PAY CODE DESCRIPTION PAY CODE DETAILS AND USES ANNUAL Annual Time Off Accrual and Usage detailed in the Time Off & Leave Guide   ANL Annual Subcode Annual used after accrual ANL OVERDRAFT Annual Subcode Annual used prior to accrual ANLCARRY Annual Subcode                        Annual carried over from prior fiscal year BRV Bereavement Paid time off for benefit eligible employees due to a death of a family member, details in  Time Off & Leave Guide   JRY Jury Duty Paid time off for benefit eligible employees for Jury duty, details in  Time Off & Leave Guide SICK Sick Time Off Accrual and Usage detailed in the  Time Off & Leave Guide    SIC Sick Subcode Accrued GW provided sick time  SIC2 Sick Subcode Accrued regulatory sick time LWP Unpaid Time Off To record unpaid time ...
Read more