DEFECT LIFE CYCLE

Objectives of Defect Life Cycle :

What is a Defect or a bug or Faults in Software Testing?

  • A Defect is an error or a bug, in the application which is created.  A Programmer while Designing and building the software can make mistakes or errors.  These mistakes or errors mean that there are flaws in the software.  These are called Defects.
  • When actual result deviates from the expected result while testing a Software Application or product then it results into a defect.  Hence, any deviation from the specification mentioned in the product functional specification document is a defect.  In different Organizations its’s called by different names like bug, issue, incidents or problems.
  • When the result of the Software Application or Product does not meet with the end user expectations or  the software requirements then it results into a Bug or Defect.  These Defects or Bugs occur because of an error in logic or in coding which results into the failure or unpredicted or unanticipated results

What is a Failure in Defect Testing?

  • Not all Defects result in Failures, some may stay inactive in the code and  we may never notice them.  Example: Defects in dead code will never result in failures.
  • It is not just Defects that give rise to failure.  Failures ca n also be caused because of other reasons.
  • Because of the environmental conditions as well a radiation burst, a strong magnetic field, or electronic field or pollution could cause faults in Hardware or Firmware. Those faults might prevent or change the execution of Software.
  • Failures may also arise because of human error in interacting with the software, eg: A wrong input value being entered or an output value being misinterpreted.

Important to understand Error, Defect and Failure

  • Error: The mistakes made by Programmer is known as an ‘Error’.  Error can be caused because of some confusion in understanding the functionality of the software, or miscalculations of the values, or misinterpretation of the value, etc.
  • Defect: The bugs introduced by Programmer inside the code are known as Defect.  This can happen because of Programmatically mistakes.
  • Failure: If under certain circumstances these defects get executed by the tester during the testing then it results into the failure which is known as failure.

From where do Defects and Failures in Software Testing Arise?

  • Errors in the Specification, Design and Implementation of the Software and System.
  • Errors in use of the System.
  • Environmental Conditions.
  • Intentional Damage.
  • Potential Consequences of earlier errors.

When do Defects in Software Testing Arise?

When do Defects on QA Testing arise? Continued…

  • Requirement 1 is implemented correctly, we understand the customers requirement, it is designed correctly to meet that requirement, built correctly to meet the design, and so deliver that requirement with the right attributes. Functionally: it does what it is supposed to do.  Non-Functionally: it is fast enough and easy to understand.
  • Requirement 2 is fine until the Software is coded, when we make some mistakes and introduce defects, they ae spotted and corrected during testing, because we see the product does not meet its design specifications.
  • Requirement 3 is harder to deal with, we built exactly what we are told but the developer makes some mistakes so there are defects in the design.  Unless we check against the Requirements definition we will not spot those defects during testing.
  • Requirement 4 defects were introduced during the definition of the requirements the product has been designed and built to meet the flawed requirements definition.

What is a Defect Life Cycle or a Bug Life Cycle in Software Testing?

What is a Defect Life Cycle Contnd…

1.New: When the Defect is Logged ad posted for the first time.  It’s state is given as ‘new’.

2.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 the corresponding Developer and the developer team. It’s state is given as ‘Assigned’.

3.Open: At this state the developer has started analyzing and working on the defect fix.

4.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.

5.Pending Retest: After fixing the defect the developer has given that particular code for retesting to the tester.  Here the testing is pending on the tester’s end.  Hence it’s status is ‘pending retest’.

6.Retest:  At this stage the Tester does the Retesting of the changed code which developer has given him to check whether the defect got fixed or not.

7.Verified: The Tester tests the bug again after it got fixed by the developer.  If the bug is not present in the software, he approves that the bug is fixed and changes the status to ‘verified’.

8.Reopen:  If the bug still exists even after the bug is fixed by the developer, the tester changes the status to ‘reopened’. The bug goes through the life cycle once again.

9.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/she changes the status of the bug to ‘closed’.  This state means that the bug is fixed, tested and approved.

10.Duplicate:  If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to ‘duplicate’.

11.Rejected:  If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to ‘Rejected’.

12.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 for the release or the bug may not have major effect on the software.

13.Not a Bug:  the state given as ‘Not a Bug’ if there is no change in the functionality of the application.  For instance, if customer asks for some change in the look and field of the application like change of color of some text then it is not a bug just some changes in the looks of the application.

What is the cost of defects in Software Testing?

  • The cost of defects can be measured by the impact of the defects and when we find them.  Earlier the defect is found lesser is the cost of defect.
  • For example if error is found in the requirement specifications then it is somewhat cheap to fix it.  The correction to the requirement specification can be done and then it can be reissued.
  • Same way when defect or error is found in the design then the design can be corrected and it can be reissued
  • But if the is error is not caught in the specifications and is not found till the user acceptance then the cost to fix those errors or defects will be way too expensive.

Conclusion :

  • Finding defects which may get created by the programmer while developing the software.
  • Gaining confidence in and providing information about the level of quality.
  • To prevent defects.
  • To make sure that the end result meets the Business and User Requirements.
  • To ensure that it satisfies the BRS that is Business Requirement Specifications and SRS that is System Requirement Specifications.
  • To gain the confidence of the customers by providing them a quality product.

 

Has one comment to “DEFECT LIFE CYCLE”

You can leave a reply or Trackback this post.

Write a Reply or Comment

Your email address will not be published.