Defect Lifecycle

                Defect Lifecycle or Bug Lifecycle is defined as ‘Different states a bug/defect passes through, from the time the defect has been identified till it is closed. 

As mentioned, once a defect has been reported in a bug tracking tool, it passes through different stages and accordingly the defect status changes. These status names and number of status differs from tool to tool.

Following is a common list of status in a defect life cycle.

Fig 1: Defect Lifecycle

 

New:

                When a defect is reported by tester in a bug tracking tool, the defect will be in ‘NEW’ state. It indicates a new bug has been reported and not yet assigned to a responsible developer.

Assigned:

                Once the new defect has been reported, the Project Lead or manager looks into the defect details and assign it to a responsible developer to get it fixed. The bug will be in ‘ASSIGNED’ state after it is assigned to a developer.

Open:

                The developer acknowledges the defect by moving to the next state ‘OPEN’. In this state the developer analyses the defect and take necessary actions. If it is a valid issue, he provides estimates and start fixing the issue. If it is an invalid issue (Please refer to Rejected state for more details), then he moves the defect to REJECTED State.

Ready to Test:

                Once the developer fixes the issue, he moves the defect state to ‘READY TO TEST’. Now the defect is ready to be tested by testers.

Verified:

                The testing team verifies the defect and if all the scenarios related to the defect are working fine, then they move it to ‘VERIFIED’ state.

Re-Open:

               When the tester test the defect and it the bug is still reproducible or any other related scenarios are broken, he Fails the defect and Re-Open the defect. After this it will be again assigned to the concerned developer to perform rework.

Rejected:

              The defect can be moved to REJECTED state for following 4 reasons.

·         Not A Bug: The defect raised by tester is not an issue and it is an expected behavior

·         Not Reproducible: The defect raised by tester is not reproducible in the latest software. It might have got fixed by some other changes.

·         Duplicate: The defect raised by tester is duplicate of some other defect.

·         No Further Action: The defect raised by tester will not be fixed in this release. This may be due to different factors like priority, time constraint, major architecture changes etc.

Closed:

             This is the final state of the bug where the testing team retest all the changes in the latest software and mark it as ‘CLOSED’.

 

 

10 Points to note before raising a defect

As soon as you encounter a defect/bug, please do the following to ensure whether it is a valid bug and then report it.

1. Note down the exact steps and try to replicate using the steps
2. If it is not reproducible, try to find the exact steps and repeat above step.
3. Try to replicate using different inputs.
4. Try to reproduce the issue in peer tester’s machine. In case if it is a machine specific issue, you can find out from this step and mention it in the bug report.
5. Make sure the QA environment is not used by developers
6. Try to clear cache/cookies and reproduce the issue.
7. View the log files and try to analyze the logs. Sometimes, there may environment issues such as SP missing etc, which can be rectified by tester itself instead of raising defect.
8. If you are not clear on the log, discuss with the developer and understand the issue.
9. Check all possible scenarios where the defect might occur and club all the scenarios in the defect.
10. Finally submit a defect if it is a valid defect and add all your analysis in your bug report.

 

Software Defect – Bug: What is a Defect/Bug?

A software bug/defect is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

Testing is a continuous process in Software Development Life Cycle. During Testing, when the tester come across any error or deviation from the expected functionality, he reports is as a defect

Defect is also knows as Bug or Issue or Incident or Anomaly etc.

A Simple Defect is written as follows.

        

Fig 1: Sample Bug Report

     

There are various Bug Tracking tools and the defect reporting differs from tool to tool. But the above ones are the common fields used to report defects. Also, the bug status changes based on the bug tracking tool. Please refer by next blog on Defect Life Cycle to know more about this.

Defect Prevention

Defect Prevention is one of the key process area for CMM Level 5.

The main purpose of Defect Prevention is to identify the root cause of the issue and prevent it from occurring again in the future by taking necessary actions.

The set of defects introduced are listed down and the root cause for them are analyzed. The trends are then observed and preventive measures are taken.

Defect Prevention process involves the following activities.

• Defect Prevention process is defined in Project Plan
• Defect Prevention Anchor is identified
• Defect Prevention Activities are implemented
• The results of DP activity is reviewed and addressed

 

Define Defect Prevention Process:

Defect Prevention Process should be defined as part of Project Plan. All standards and guidelines should be in place.

 

Defect Prevention Anchor:

Defect Prevention Anchor should be identified. He is the person responsible for conducting DP meeting and carrying out DP activities

 

Defect Prevention activities:

• Kick off meeting

Kick off meeting is conducted to make the team members aware of the DP process to be followed in the project. The DP anchor will be explaining about the process and meeting schedule and what is expected from the team members

• Casual Analysis Meeting:

The DP anchor will come up with the list of defects to be discussed in the meeting. This meeting will be attended by all responsible developers and testers in the project.

 

All the defects are analyzed/discussed one by one and the root cause for each defect is identified.

 

Based on the root cause and analysis, the Defect-Cause, Severity and Priority are determined for each defect as shown below.



Example: Defect Classification





After the defects are classified to appropriate cause category, a Pareto Chart is prepared to show the defect category and its frequency of occurrence.

            

Example: Pareto Analysis Chart

 



While discussing the defect causes in a brainstorming session, there may be different opinions. All the possible causes can be represented using Cause-and-Effect diagram also known as Fishbone Diagram or Ishikawa Diagram as shown below

 

Example: Fishbone Diagram

• Measures to Address the Root Causes:

Based on the Casual Analysis, top Problem Areas are identified and preventive measures to avoid the causes in future is recorded. Problem Areas, Benefits of addressing the problem, Action Items, the Person responsible for the action and actual implementation date of the action are all recorded in Casual Analysis and Resolution Report.

Defect Prevention Activity Review:

                The Defect Prevention Activity Results and Action Items status should be reviewed continuously.

Monitor whether the Defect Cause has been eliminated based on the action taken.

The DP activity data and results are recorded, so that other similar projects in the same organization can use it.

Finally the Software Quality Assurance group audits the DP activity report and use it to determine the CMM Level of the project.

 

 

 

 

Root Cause Analysis in Software Testing

Root cause Analysis (RCA) is an important activity in a project and hence I chose to write about this first in my blog.
There is a common misunderstanding that RCA is developer’s responsibility and tester need not worry about it. RCA has to be done both from tester and developer end, each in a different perspective. Since the defect is found by the Tester, he/she should be aware of all the steps to reproduce. If we go little further to analyze we will be able to figure out the issue to some extent.

Personally I don’t recommend testers to spend time digging into the code to find issue, but most of the issues root cause can be found out on analysis.

Root Cause Analysis: It is a process of analyzing the bug/defect and figure out its root cause.

RCA is usually performed officially when there is any production Issue is caught. It may be also performed whenever QA reports a bug. This helps us to fix the original issue instead of providing quick fixes. Based on the RCA, we can take decision to prevent the occurrence of defect in future.

RCA has to incorporate all the below points.

·         Analyzing the exact issue

·         What caused the issue

·         How it can be prevented in future

Analyzing the issue:

                Whether an issue is reported by tester or Production, the issue has to be analyzed thoroughly. We should try to gather as much information possible about the issue. For example, if an exception issue is found, we need to look,

è What type of exception it is?

è Whether it crashes the application or not?

è Is it machine specific or occurs in all machines?

è Exact steps to reproduce.

è Is it consistently reproducible or an inconsistent issue?

o   Almost all issues can be reproduced consistently if we find the root cause/exact steps

è Any information can be obtained from log files

o   Log files will have the details about the exception and at which point of code it is thrown. Even if there is any issue with environment setup, it can be found out from log files like missing tables, Stored Procedure issues, constraint violation etc.

What caused the issue?

             There are many factors which might have caused the issue like,

·         Ambiguous/ missing requirements

·         Design Issue

·         Incorrect Implementation

·         Environment Setup Issues

·         Insufficient Testing

·         Data Issue

·         Integration issues

·         Communication issues

·         Oversight

            Mostly the causes will be a combination of two or more above factors.

How it can be prevented in future:

                Once we find the root cause of the issue, we should try to take a preventive action to avoid it occurrence in future. For this Defect Prevention meeting will be conducted to discuss all the issues, its causes and come up with a preventive measure to avoid these causes. I will cover this in my next post in detail.

About Me!

About Me:

Hi I am Priya Subramanian. I have 9+ years of Software testing Experience in IT industry.

The main intention of starting this blog is to enhance my learning by sharing all my knowledge and project experiences with you all.

You can expect wide range of testing topics related to Manual, Automation, Database, Web Service, API, PerformanceTesting etc from my blog.

Happy Testing!