Bug Life Cycle

Bug Life Cycle (Defect Life cycle) is the journey of a defect from its identification to its closure. The Life Cycle varies from organization to organization and is governed by the software testing process the organization or project follows and/or the Defect tracking tool being used.

Nevertheless, the life cycle in general resembles the following:

1. NEW
   When the bug is posted for the first time its status is NEW.
2. ASSIGN:
   When the lead of testing team feels that the bug is genuine, he assigns the bug to the development team, hence the status is changed to ASSIGN.
3. OPEN:
   When the developer analyzes and works on the bug to fix it, the status is changed to Open.
4. FIXED:
   When the bug is fixed by the developer, the status is changed to Fixed.
5. PENDING RETEST:
   After fixing the bug the developer give the specific piece of code to the tester to test again, hence the bug is at the tester’s end so the status is changed to Pending Retest.
6. RETEST:
   The tester tests the bug again so the status is Retest.
7. VERIFIED:
   After testing again if the tester feels that the bug is now fixed, he/she changes the status to Verified.
8. REOPEN:
   If the tester feels that the bug is still not fixed, he/she change the status to reopen.
9. CLOSED:
   If the bug is fixed, the status is changed to Closed.
10. DUPLICATE:
    If the bug is repeated twice or the two bugs mention the same concept of bug, then one bug is changed to duplicate.
11. REJECTED:
    The status is changed to Rejected if the developer feels that the bug is not genuine.
12. DEFERRED:
    The status is changed to deferred if the developer feels it might be fixed in the later releases or the bug has low priority.
13. NO BUG:
    The status is changed to No Bug if there is no change in functionality of the application.

Service Level Agreement (SLA)

A service level agreement is a contract between the service provider and the end user that defines the level of service expected from the service provider. It focuses on WHAT is delivered not on how it is delivered.

SLAs measure the service provider’s performance and quality in a number of ways. Some metrics that SLAs may specify include:

• Availability and up-time -- the percentage of the time services will be available.
• The number of concurrent users that can be served.
• Specific performance benchmarks to which actual performance will be periodically compared.
• Application response time.
• The schedule for notification in advance of network changes that may affect users.
• Help desk response time for various classes of problems.
• Usage statistics that will be provided.

SLAs are a critical component of any vendor contract. Beyond listing expectations of service type and quality, an SLA provides remedies when requirements aren't met.

Requirements Trace-ability Matrix (RTM)

In the previous post I discussed the software Testing life cycle and in the design phase of the STLC a requirements trace-ability matrix is designed.
So let's discuss what requirements trace-ability matrix is.

Requirements Trace-ability Matrix:

The Requirements Trace-ability Matrix (RTM) is a document that links requirements throughout the validation process. The purpose of the Requirements Trace-ability Matrix is to ensure that all requirements defined for a system are tested in the test protocols.

Software Testing Life Cycle (STLC)

Software testing life cycle refers to a testing process which has specific steps to be executed in a definite sequence in order to meet the quality goals.

In STLC process, each activity is carried in a planned and systematic way. There are some phases of STLC that varies through organizations but the basis remains the same.

Phases of STLC are:

• Requirements Phase
• Planning 
• Design
• Test Environment Setup
• Test Execution
• Test Reporting

1. Requirements Phase:
   
   During this phase, analyze and study the requirements. Have brainstorming sessions with other teams and try to find out whether the requirements are testable or not. This phase also defines the scope of the testing. If any feature is not testable communicate it so that the mitigation strategy can be planned.
   In short you review the software requirements/design if they exist and carry out ‘Review Defect’ reports.
   
   
2. Planning Phase:
   
   In practical scenarios, test planning is the first step of the testing process. In this phase we identify the activities and resources that would help in meeting the testing objectives. During planning, we also try to identify the metrics and the methods of gathering and tracking those metrics.
   Once you gathered a general idea of what needs to be tested you plan for the tests.
   Test plan, test estimation and test schedule are the deliverable s.
   
   
3. Design Phase:
   
   Design and detail the tests on the basis of detailed requirements/design of the software. 
   Test cases, scripts, tests data and requirements trace-ability matrix are deigned.
   
   
4. Test Environment Setup:
   You setup the test environment (server, client, networks etc.) with the goal of replicating the end user’s environment.
   Deliverable: Test Environment.
   
   
5. Test Execution:
   Execution of test cases in the test environment to see whether they pass, and carry out the test results and defect reports.
   
   
6. Test Reporting:
   You prepare various reports for various stakeholders and carry out final test results, test/defect metrics, test closure report.