Defect cycle or defect life cycle is ride of a defect from discovering defect to closure of defect. Defects management in defect cycle is important to ensure the software quality. Preventing, identifying, rectifying defect is important to improve the quality. Defect is managed and tracked easily throughout the defect cycle with the use of defect tracking tools like JIRA, Mantis, Team Service, Bugzilla, Redmine etc. In a project identifying defects in early stage and fixing will take less cost when compare with identifying and fixing defects in later stage of the project. A tester need to identify valid defect and raise the defect with all the detail and make sure the defect gets closed. We also need to make sure the closed defect is verified and in the close stage in future releases also. If it gets reopen that should be resolved, verified and closed again. Defect have several stage from identification to closure. Managing all the defects on particular software project is important to complete the project successfully.
Stages of defect in defect life cycle:
Identifying defect:
To identify defect, the tester should know exactly what the expected behavior of the system is. While doing the test execution tester will compare with the expected behavior and if it vary, there is a defect discovered. Tester should think is non-functional areas such as usability, user friendly also and if there is any problem in that that also need to be raised as a defect or communicate as an improvement. Always tester should make sure the exact expected result is mentioned along with the defect when report the defect. Tester should be concern and raise the valid defects. Defects that hold the state New, Assigned and Reopened are falls under this stage. After this stage defect shall be resolved.
Resolving defect:
Tester and developer should rectify the defect without the negative impact to other areas. While resolving the defect, the expected behavior should work correctly and defect should not be there anymore. Defects that hold the state fixed, duplicated, cannot reproduce, cannot resolve and not a defect are under this stage. After this stage the defect is ready to retest.
Retesting defect:
After developer rectify the defect, tester will retest the particular defect. Tester will test whether the defect is fixed and the expected behavior of the system is applied. Defects that hold the state fixed, duplicated, cannot reproduce, cannot resolve and not a defect will be verified in this stage. Once retested the defect transfer either to reopen or closed state. Defect’s journey is end when the defect is closed. But the defect should be verified in later releases also to check the expected behavior is working and defect is no more occurring.
States in defect life cycle:
New:
When a defect is encountered in the software project, the tester is supposed to raise it. At the very first time when the defect is raised, the stage of the defect is ‘New’. Tester should always analyze and make sure that it is a valid defect. Tester should know what is the expected result whenever encounter a defect.
Assigned:
Once the defect is raised it will be assigned to the developer to resolve the defect. Tester should know to which developer the particular defect should be assigned. Once assigned the defect is transfer to the developer hand.
Fixed:
Developer will analyze, check and fix the defect. While fixing the defect developer should make sure there is no other negative influence to other areas in the software.
Deferred:
There are some instance the defect is valid but it will be fixed in the future releases, then the defect transfer to deferred state. As a good practice when deferred the defect, the decision needs to be taken after discussing with the team members.
Duplicate:
There are some cases the defect is valid but it’s been already reported either by another tester or in another form. At this time developer will mark the defect as duplicate defect.
Not a defect:
If the defect is not a valid defect then the developer will state the defect as ‘Not a defect’.
Cannot reproduce:
There are some instance the developer can’t reproduce the defect, then the developer will mark as cannot reproduce. It’s better to check with the tester and try to re-create the defect. Some defects are data specific or environment specific. At this time it’s good to check with tester and find the root cause and resolve the defect.
Cannot resolve:
There can be a defect which cannot be rectified due to any limitation like technical limitations. At this time the defect goes to the state cannot resolve. When we cannot resolve a defect, we need to communicate that to the team and if need this needs to be communicated to the client or end users as well.
Reopen:
After the state of fixed, duplicate, deferred, cannot reproduce, and cannot resolve, the defect transferred to tester’s hand again for verification. Tester should retest whether the defect is fixed or not. If the defect is not resolved then the defect will be reopened. While reopen the defect again the defect goes to developer’s hand.
Closed:
While tester retest the defect if the defect is fixed then the defect goes to ‘Closed’ state. Tester should verify the closed defect in future and make sure the defectis not happening any more in the software. If the closed defect is encountered again in the software, it will be reopen and travel from assign state again.
Defect life cycle:
Below diagram explain the flow of the defect throughout the defect life cycle.
Defect management:
First of all it is important to prevent defects as possible in software. Developer should keep this in mind while developing. Testers should discover the defect as quick as possible. Cost and the effort is less to fix the defects identified at the early stage in the software development life cycle. Once the defect is discovered it will be recorded and tracked. Defect is recorded in detail with all the required details. Defect tracking is important to close the defects and reach the appropriate quality. Then the discovered defect should be rectified properly and maintain that it will not occur again in the software. Defect is analyzed and root cause will be find, to improve the development and software quality. Defects and defect reports shall be analyzed and help to improve the software quality. It also helpful to improve the individual team members. They could improve their skills while analyzing the defects.
Detail in defect:
- Summary
- Type (E.g. UI, Function, Performance etc.)
- Priority
- Severity
- Reporter
- Reported date
- Assigned to
- Steps to reproduce
- Actual result / Defect
- Expected result
- Test environment detail
- Software version
- Software information (E.g. Browser, database etc.)
- Hardware information (E.g. Processer speed, RAM etc.)
- History (What, who and when a defect is modified, State changes etc.)
- Any additional note
Conclusion:
Defect can be managed and can flow in different cycle in different organizations. It’s essential to document the defect cycle in the organization. Defect is discovered, report with all the required detail and resolved to improve the quality of the software. Defect is managed and tracking using several tools. Defect is generally identified by the tester and resolved by the developer and retest by the tester. It’s important to make sure that the defect is not harm any other sections in software. Also it’s important to make sure that the defect will not occur again in the software. Defect reports are helpful to take decision during the project. Defect report will provide clear understanding on where the project is stand. It provide transparent among organizations. Defect report shall be analyzed to do improvement in future software projects.