Defect life cycle in software testing wiki

Facebook Badge Software Testing. Saturday, November 12, Bug life cycle at Saturday, November 12, Email This BlogThis! Unknown says: April 13, at PM.

Raksha says: August 27, at PM. Unknown says: November 11, at PM. Stephen says: November 24, at PM. Unknown says: June 3, at PM. Nandhini says: August 8, at PM. Unknown says: April 3, at PM. Srinithi says: May 15, at PM. Anonymous says: May 23, at PM. Chad says: July 30, at AM. As you might be aware by now that test execution is the phase where the tester would be actually executing the test scripts.

The process of execution of test scripts varies from company to company and might be different in different projects within the same company as well. Nowadays there are tools available for test execution, tools like — Quality Center, Microsoft visual studio and so on. The actual execution process of performing each step to compare actual and expected result remains the same for the functional tester irrespective of tools used.

In this article will see about defect life cycle in software testing. When a tester finds that the actual testing result is not equal to the expected result, a defect is logged.

There are some of the mandatory fields which are common across the various defect logging tools, these fields are —.

Defect Life cycle starts from logging a new defect. A Tester may assign a defect to a developer or a development lead. This decision of defect assignment varies from project to project. At some workplaces there is defect life cycle process to assign it directly to a respective developer and at some places the defect is first assigned to a dev lead and the dev lead in turn assigns it to a developer. Developer will analyze the defect to check if it is reproducible.

Here the most important contribution from the tester is to include all the necessary details in the defect. Defect Summary, Defect detailed description are the fields which helps the stakeholders to understand the defect in one go. Defect Summary should always have only the high level information of the defect.

At the same time it should have sufficient information to describe the overview of defect in one line. Test environment where the defect was found. Often projects have multiple test environments where the test team performs testing. The purpose of having various environments is that it provides flexibility within the development and test team to have the code deployed on any of the available environment to start off the testing on time.

There are times when the Product test also called as system test and UAT testing overlaps, hence having multiple environments is a must to continue testing in parallel.

There are cases when the development team needs an additional environment to debug the issues reported by the testing team. Also the develop team has a dedicated environment for unit testing task. Hence with multiple environments, it is must to mention in the defect a particular environment where the issue was found. Scenario is the set of steps performed by the tester which led to a defect. Assigned — After the bug is logged and posted, it needs approval from the lead tester to make sure whether the bug is genuine or not.

If the bug is found to be genuine, it is assigned to corresponding developer or developer team. This state is known as Assigned. Open — This status refers to the life cycle step in which the developer has started analyzing and working on how to fix the bug permanently and is known as Open state.

Fixed — After working and analyzing an Open defect, the developer makes necessary code changes and makes sure that the changes made completely fixes the bug and then passes it on to the testing team. This life cycle state in which the developer fixes the bug is known as Fixed state. Pending Retest — After the defect is fixed by the developer and is passed on to the tester, the tester needs to retest the fixed code to make sure it works just as expected.

This state of bug life cycle is known as Pending Retest. Retest — In this state, the pending code that needs to be retested is tested to make sure that the changes made by the developer fixes the defect or not. This state is known as Retest state. Verified — The tester checks again the code changes made by the developer to fix the bug. The purpose of Defect life cycle is to easily coordinate and communicate current status of defect which changes to various assignees and make the defect fixing process systematic and efficient.

Defect Status or Bug Status in defect life cycle is the present state from which the defect or a bug is currently undergoing. The goal of defect status is to precisely convey the current state or progress of a defect or bug in order to better track and understand the actual progress of the defect life cycle.

The number of states that a defect goes through varies from project to project. Below lifecycle diagram, covers all possible states.