Article by: Amir Ghahrai
Introduction
Finding defects and reporting defects are the main activities of the testing. In this article I endeavour to explain the Software Defect Lifecycle and the Defect Process in general. I will list all the activities for each stage of the process that are commonly performed in a typical software testing environment.
Also, in this article, I have assumed that the development team have developed a software application and is at least to a stage that is ready for testing.
The process is not leaning to any particular development model as I believe this generic process is suitable for any development model. In other words, the process in itself is generic for all development models; however, the amount of activities, required inputs and produced outputs will depend on the type and complexity of the application, organisation’s view on testing and the structure of the project.
Defect Lifecycle
Generally speaking, the defect life cycle is made up of four stages. (See Figure 1, below).
Stage 1, defects are found and reported.
Stage 2, defects are reviewed and delegated.
Stage 3, defects are debugged and removed.
Stage 4, removed defects are confirmed.
Figure 1: Showing the four stages of the defect lifecycle indicated by dark curved arrows and the activities performed at each stage (rectangles on the arrow). The inner circle indicates the status of the defect at each stage of the lifecycle.
N.B. This model is only applicable to source code errors (that are decided to get fixed) and not document errors.
Stage 1: Defects are found and reported by the testing team (presumably)
Software released to testing
After the development team have developed the software and is ready for testing, the software is then released to the testing team. Items released to testing generally include Software Requirement Specification (SRS), Software Design Specification (SDS), application source code (for code walkthroughs and inspections), executable application and any third party libraries that may be required to make the application work.
Testing team prepare and setup the testing environment; install the application and any required third party libraries.
Testing team start testing
Once the application is installed, members of the testing team will start testing the application based on the Test Procedures. The activities may include Functional Testing, Non-Functional Testing, Performance Testing, etc.
Defects may be found
During testing testers may find defects either in the application or in the documents e.g. test procedure.
If a defect is found, either in the application (source code) or in the document, a defect report form is filled and passed on to the test team lead or test manager for review. (There is a detailed explanation on what to include in the defect form in this article: Defect Reporting).
- Defect Status is: Open and Not Reviewed
Stage 2: Defects are reviewed and delegated
Defects get reviewed first by test team lead for any obvious mistakes by the testers, such as missing information on the defect form (see Defect Reporting) and then reported to software development manager for further review.
A meeting is scheduled which includes members of the development team and testing team to discuss the validity, severity and priority of the defects.
At this stage, defects are categorised into three different states:
Not a defect
Defect will be fixed
Defect won’t be fixed in this release
- Defect Status is: Reviewed & Assigned
Stage 3: Defects are debugged and removed
Fixing defects
After the meeting and agreed actions, the software development manager delegates defects to different developers in the team.
For defects that are not going to be fixed in the current version of the software, an impact analysis must be performed to identify any potential failures that may occur as a result of the existing defects in the system.
Developers will analyse the source code to identify the root cause and ultimately remove the defect.
- Defect Status is: Being Debugged
Stage 4: Removed defects are confirmed
Confirmation Testing and Regression Testing
The “Fixed” version of the software will be released to the testing team and testers will start to test the “fixed” software. At this stage, two types of testing are performed by the testers: confirmation testing and regression testing.
Based on the outcome of the confirmation testing, the “fixed” defects are either confirmed as fixed (defect is removed) or not fixed (defect still exists).
For defects that are fixed, their status is changed to fixed and can be closed.
For defects that are not fixed, i.e. they still exist in the system, they go round the cycle again, i.e. are reported to the development team, gets reviewed by the development team, faults are removed, a new version of software is released to testing for confirmation + regression testing and so on.
This cycle is repeated until all the defects (that were decided to be fixed in the current version) are fixed and verified by testers.
- Defect Status is Fixed & Closed
The model explained above is a generic model explaining the defect lifecycle. Defect management is an important aspect of software testing and if managed properly it should reduce a lot of overheads. Following a defined lifecycle can help in managing the defect process and increase the productivity of the testing team.
