Software Bug Life Cycle

8/9/2019 Software Bug Life Cycle

1/8

Software Bug Life-Cycle

Defect Life Cycle is the Cycle thru which a defect goes starts when defect found & ends when defect is

closed after ensuring its not reproduced. Defect Life cycle is related to Bug found during testing so it

doest depend on Manual & Automated Testing.

Or

The time span between the first time bug is found by the tester the Bug status is New

and closed successfully with status is Closed in between the bug travelled with different

stages like open, assign, rejected, fixed is called Bug Life Cycle.

Introduction:

Bug can be defined as the abnormal behavior of the software. No software exists without a bug. The

elimination of bugs from the software depends upon the efficiency of testing done on the software. A bug

is a specific concern about the quality of the Application under Test (AUT).

Bug Life Cycle:

In software development process, the bug has a life cycle. The bug should go through the life cycle to be

closed. A specific life cycle ensures that the process is standardized. The bug attains different states in

the life cycle.The life cycle of the bug can be shown diagrammatically as follows:


2/8


3/8

The different states of a bug can be summarized as follows:

1. New 5. Verified 9. Rejected 13.Testers Error

2. Open 6. Deferred 10. Closed

3. Assign 7. Reopened 11. As Per Design

4. Test 8. Duplicate 12.Hold

Description of Various Stages:

1. New:When the bug is posted for the first time by the testers, its state will be NEW. This means that

the bug is not yet approved.

2. Open:After a tester has posted a bug, the lead of the tester approves that the bug is genuine or not

and he changes the state as OPEN.


4/8

3. Assign:Once the lead changes the state as OPEN, he assigns the bug to corresponding developer or

developer lead. The state of the bug now is changed to ASSIGN.

6. Rejected:If the test lead/developer feels that the bug is not genuine, he rejects the bug. Then the state

of the bug is changed to REJECTED.

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

6. Re-Test:Once the developer fixes the bug, he has to assign the bug to the testing team for next round

of testing. Before he releases the software with bug fixed, he changes the state of bug to Re-Test. It

specifies that the bug has been fixed and is released to testing team.

7. Reopened:If the bug still exists even after the bug is fixed by the developer, the tester changes the

status to REOPENED. The bug traverses the life cycle once again.

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

8. Verified:Once the bug is fixed and the status is changed to Re-Test, the tester tests the bug. If the

bug is not present in the software, he approves that the bug is fixed and changes the status to

VERIFIED.

10. 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 changes the status of the bug to CLOSED. This state means that the bug is fixed,

tested and approved.

11) Hold:Whenever the defect is raised, that is associated with lack of information; usually such defectsare not accepted by the developers. It is because with existing information, one can neither call it as

defect nor not a defect. In this situation the developer assigns the status known as'Hold'.

12) As Per Design:In case the hasty implementation of the requirements without the intimation of Test

Engineer there is always a possibility that the Expected Value will not match the Actual Value. Obviously,

Test Engineer raises a defect which is not at all accepted by developer as the implementation is done as


5/8

per the requirements of the customer. Hence he will assign the status known as'As Per Design',

indicating the functionality is as per the requirements.

13)Tester's Error:In case the Test Engineer does not understand the requirement properly, here is a

possibility of creating wrong test case to perform wrong testing and there by result is wrong defect. These

wrong defects are not accepted by the developer and he will assign a status known as'Tester's Error',

indicating testing is not done properly.

While defect prevention is much more effective and efficient in reducing the number of defects, most

organization conducts defect discovery and removal. Discovering and removing defects is an expensive

and inefficient process. It is much more efficient for an organization to conduct activities that prevent

defects.

'BUG LIFE-CYCLE'has the following statuses of defect.

a)New:Whenever a defect is raised by the Test Engineer for the first time, he will always give the status as

'New/Open'indicating is raised afresh, is not yet dealt with developer.

b)Fixed For Rectification:Once the developer accepts the defect, he will rectify it and once the defect is

rectified, he will give the status to the defect as'Fixed for Verification', indicating the defect is rectified

and ready for verification.

c) Closed:Once the Fixed for Verification is sent to Test Engineer, on verification, if the Test Engineer

realized that the defect is really rectified by the developer, he will assign the status as'Closed', indicating

that this defect is not at all present in the product.

d) Re-Open:On verification the Test Engineer realizes that the defect is not really rectified properly, he

will always assign the status as'Re-Open', indicating that the defect is still there in the product in spite

of developers effort for rectifying it.

e) Hold:Whenever the defect is raised, that is associated with lack of information; usually such defects

are not accepted by the developers. It is because with existing information, one can neither call it as

defect nor not a defect. In this situation the developer assigns the status known as'Hold'.

f)As Per Design:In case the hasty implementation of the requirements without the intimation of Test

Engineer there is always a possibility that the Expected Value will not match the Actual Value. Obviously,

Test Engineer raises a defect which is not at all accepted by developer as the implementation is done as


6/8

per the requirements of the customer. Hence he will assign the status known as'As Per Design',

indicating the functionality is as per the requirements.

g)Tester's Error:In case the Test Engineer does not understand the requirement properly, here is a

possibility of creating wrong test case to perform wrong testing and there by result is wrong defect. These

wrong defects are not accepted by the developer and he will assign a status known as'Tester's Error',

indicating testing is not done properly.

Statuses associated with the Bug:

New:

When a bug is found/revealed for the first time, the software tester communicates it to his/her team

leader (Test Leader) in order to confirm if that is a valid bug. After getting confirmation from the Test Lead,

the software tester logs the bug and the status of New is assigned to the bug.

Assigned:

After the bug is reported as New, it comes to the Development Team. The development team verifies if the

bug is valid. If the bug is valid, development leader assigns it to a developer to fix it and a status of

Assigned is assigned to it.

Open:

Once the developer starts working on the bug, he/she changes the status of the bug to Open to indicate

that he/she is working on it to find a solution.

Fixed:

Once the developer makes necessary changes in the code and verifies the code, he/she marks the bug as

Fixed and passes it over to the Development Lead in order to pass it to the Testing team.

Pending:

After the bug is fixed, it is passed back to the testing team to get retested and the status of Pending

Retest is assigned to it.

Retest:

The testing team leader changes the status of the bug, which is previously marked with Pending Retest to

Retest and assigns it to a tester for retesting.

Closed:

After the bug is assigned a status of Retest, it is again tested. If the problem is solved, the tester closes it


7/8

and marks it with Closed status.

Reopen:

If after retesting the software for the bug opened, if the system behaves in the same way or same bug

arises once again, then the tester reopens the bug and again sends it back to the developer marking its

status as Reopen.

Pending Reject:

If the developers think that a particular behavior of the system, which the tester reports as a bug has to

be same and the bug is invalid, in that case, the bug is rejected and marked as Pending Reject.

Rejected:

If the Testing Leader finds that the system is working according to the specifications or the bug is invalid

as per the explanation from the development, he/she rejects the bug and marks its status as Rejected.

Postponed:

Sometimes, testing of a particular bug has to be postponed for an indefinite period. This situation may

occur because of many reasons, such as unavailability of Test data, unavailability of particular

functionality etc. That time, the bug is marked with Postponed status.

Deferred:

In some cases a particular bug stands no importance and is needed to be/can be avoided, that time it is

marked with Deferred status.

Guidelines on deciding the Severity of Bug:

i)Fatal Defects:If at all the defects are associated with navigational blockages and non-availability of

important features/objects/application windows are known as Fatal Defects. Example:- 404 Page not

Found Error

ii) Major Defects:If the defects are associated with wrong functionalities, such defects are known as

Major Defects. Example: - Wrong Calculations

iii)Minor Defects :In case the defects are associated with inconsistency, alignments, spelling issues and

look & feel issues, such defects are known as Minor Defects. Spelling mistakes, improper alignment of the

objects


8/8

IV) Suggestion:Strictly speaking, suggestion is not a defect. In fact it is a note given by testers to the

developers in order to add value for the application. Example:- Suggestion for the modification of Error

Messages

Guidelines on deciding the Severity of Bug:

Indicate theimpacteach defect has ontesting effortsor users and administrators of the application

under test. This information is used by developers and management as thebasisfor assigningpriorityof

work on defects.

A sample guideline for assignment of Priority Levels during the product test phase includes:

1. Critical / Show Stopper An item that prevents further testing of the product or function

under test can be classified as Critical Bug. No workaround is possible for such bugs. Examples of

this include a missing menu option or security permission required to access a function under

test.

.

2. Major / High A defect that does not function as expected/designed or cause other

functionality to fail to meet requirements can be classified as Major Bug. The workaround can be

provided for such bugs. Examples of this include inaccurate calculations; the wrong field being

updated, etc.

.

3.Average / Medium The defects which do not conform to standards and conventions can be

classified as Medium Bugs. Easy workarounds exists to achieve functionality objectives. Examples

include matching visual and text links which lead to different end points.

.

4. Minor / Low Cosmetic defects which does not affect the functionality of the system can be

classified as Minor Bugs.

Priority -i) Critical ii) High iii) Medium iv) Low

Documents

Software Bug Life Cycle