SDLC SOP 1061 - Incident Tracking

From OpenSDLC

Jump to: navigation, search

Contents

SDLC SOP 1061 - Incident Tracking

Objective:

The objective of this Standard Operating Procedure (SOP) is to provide a consistent methodology to ensure that “defects” or “bugs” identified in the production environment are reported, tracked, communicated, and resolved in an efficient manner.

Scope:

A “defect” occurs when the production system functionality is not performing in accordance with the Business/Users needs. This procedure is used to manage production source code defects and is not intended to manage system environment problems such as hardware and environment problems.

Owner:

Operations


Definitions

Production defects must be properly managed to ensure that:

  • All Defects are properly documented, formally processed, quickly analyzed and resolved
  • Defects are properly tracked before they are fixed
  • Effective communication is supported between the multiple teams involved in the testing and validation process, namely the Technical Support group, the Quality Assurance, the Operations group and the Developers
  • Higher overall quality is achieved.


Process Flow Diagrams

Incident Tracking Overview

File:SOP1061-01.gif

Roles and Responsibilities

Role Responsibility
Defect Reporter Production defects can be reported by internal SDLC staff or by Internet Service Providers(ISPs), Affinity groups, or Enterprise partners. For the remainder of the document, the person or group hat reports the production defect will be referred as the defect reporter.


Technical Support The department that provides support to clients and end users (first level support) is the 'Technical Support department. This department interfaces with SDLC’s customers to provide training and support once the system is turned over to the customer. These customers call Technical Support for help desk support and to report production defects. In this procedure, Technical Support will act as the funnel for reporting all production defects.
Quality Assurance Quality Assurance is responsible for ensuring all defects are properly documented, formally processed, quickly analyzed and resolved. Once a defect has been resolved by Development, Quality Assurance retests the defects to ensure the system will function correctly when the code is turned-over to production.
Development Development is responsible for responding quickly to production defect logs. This

team analyses, codes, tests and resolves all assigned defects.



Metrics

Metric Description
Cycle Time The number of days or hours it takes to complete requirements for a SDLC Business Gate and/or milestone.
Defects Instances of failure to pass specific tests or quality measures or to meet

specification/acceptance criteria. These are recorded and assessed throughout a project and reported at the end of the project.

Change Agents Individuals who analyse a process and recommend ways to improve it, successful or not in itsadoption, will be reported to Engineering Department management.These individuals will receive recognition for their effort to compress cycle times and/or improve quality.


Procedure Activities

Gate/Activity Description

File:SOP1061-02.gif

Defect Reporter In order to report a defect, the defect reporter must fill out a Production Defect Form and forward it via e-mail to Technical Support.
For internal SDLC defects the defect reporter will send the Production Defect Form to the “SDLC Bugs” email address that will be monitored by Technical Support.
For external defects the defect reporter will send the Production Defect Form to the Technical Support email address.
Technical Support Technical Support will act as the funnel for reporting all production defects.
Technical Support, upon receipt of the Production Defect Form has at most two business days to forward the e-mail to Quality Assurance.Defects with an Emergency Severity Level need to be forwarded as soon as possible and should be done within four of hours of receipt.
Quality Assurance Upon receipt of the Production Defect Form from Technical Support, a designated Quality Assurance team member verifies whether or not the defect exists by trying to reproduce it in the production environment.
Upon receipt of the Production Defect Form from Technical Support, a designated Quality Assurance team member verifies whether or not the defect exists by trying to reproduce it in the production environment.
Defect cannot be reproduced\ The designated Quality Assurance team member sends the Production Defect Form back to the defect reporter requesting more detailed information about the steps needed to reproduce the defect.
Defect can be reproduced The designated Quality Assurance team member views the Production Defect Tracking Tool to see if the defect has already been logged before making a new defect entry into the tool.
Defect is already in the tracking system The designated Quality Assurance team member updates the current entry in the tool to reflect any new information supplied on the Production Defect Form, which may assist development in fixing the defect. The defect reporter’s name is also entered, so he/she can be notified when the defect is fixed.


Defect does not exist in the tracking system The designated Quality Assurance team member creates a new entry in the tool by entering all required fields (see below).
The following information needs to be captured in the Production Defect Tracking Tool (SQA Manager) for all new defects:
  • Defect Reporter’s name
  • Defect Reporter’s organization
  • Description of the defect
  • Symptoms
  • Steps to Reproduce
  • Date/Time defect occurred
  • Browser Type
  • Severity Level (Emergency, High, Medium, Low)
  • Defect status (Open, Resolved, Closed)
  • Date Opened
  • Date Resolved
  • Date Closed
  • Assigned Developer
  • Resolution Type

Defects recorded in the Production Defect Tracking Tool (SQA Manager) may have one of three statuses:

  • OPEN: A newly recorded defect is automatically assigned an “Open” status until an

action to correct it has been taken by the responsible developer .

  • RESOLVED: When the responsible developer corrects and re-tests the defect, he/she updates the status to “Resolved”, before referring it back to the QA team for validation.
  • CLOSED: When the QA team re-tests the software and verifies that the system is now functioning in accordance with the specification. He/she will “Close” the defect.


The designated Quality Assurance team member reviews the Severity Level set by the defect reporter. If the designated Quality Assurance team member does not agree with the severity he/she may change it with the approval of the QA Manager.
Defects recorded in the Production Defect Tracking Tool (SQA Manager) may have one of four Severity levels Each Severity level directly corresponds to action taken to resolve the defect as shown in the table below:
Emergency: These defects are showstoppers and need to be fixed as soon as possible and constitute the need for an Emergency Push. All Emergency Pushes must handled through Emergency Push (Surgical Push) Procedure and will need the appropriate approvals.

Examples include:

  • Site instability impacting the majority of users.
  • Major software component/feature like “News” is broken.
  • The ability to bring the sight down.

High: These defects are showstoppers but can wait to be fixed in the next scheduled “Bug Fix Release” or “Current release” which ever is sooner. All changes to the current release must be handled through the Change Control Procedure and will need the appropriate approvals.

Examples include:

  • Show stopping bugs where SDLC is losing business/revenue. Can this really wait?
  • The potential to substantially impact a majority of users is high.

Medium: These are defects are not showstoppers and can be fixed as part of the Current Release. A Change Request Form should be completed and forwarded to the Project Manager of the current release. All changes to the current release must be handled through the Change Control Procedure and will need the appropriate approvals.

Examples include:

  • Broken functionality (what kind of nctionality?)
  • Error messages
  • Bad links
  • Problems that make SDLC look bad

Low: These are defects that typically involve minor formatting problems and can be fixed as part of a future release. A Service Request Form should be completed and forwarded to the appropriate group as defined in the Release Planning Procedure (SOP1005).

Examples include:

  • Alignment
  • Typos
  • Errors in navigation
  • Rarely encountered problems
QA Manager The QA Manager makes sure the defect reporter has filled out the Emergency Push Sign-off Form and has obtained the appropriate approvals as defined in the Emergency Push Procedure.If the defect reporter is from an external source (ISP, Partner, Affinity group) Technical Support is responsible for filling out the Emergency Push Sign-off Form.A Development resource will be assigned by the Development Project Manager as described in the Emergency Push Procedure.
The designated Quality Assurance team member,when entering the defect into the Production Defect Tracking Tool,contacts the Development Project Manager to identify the developer who will work on the defect. The developer’s name is entered into the tool, which generates an e-mail message to the developer.
The designated Quality Assurance team member,when entering the defect into the

Production Defect Tracking Tool,does not assign a developer. The 'designated Quality Assurance team member forwards the Production Defect Form to the 'Project Manager of the current release. The Project Manager will handle the Production Defect Form the same way it would handle a Change Request Form. If the request is approved, the Development Project Manager will assign a developer.

The designated Quality Assurance team member, when entering the defect into the Production Defect Tracking Tool does not assign a developer. The developer will be assigned during the Definition phase of a future release
Developer The developer corrects and re-tests the defect. Upon successful test execution, the developer goes into the Production Defect Tracking Tool and updates the defect status to “Resolved”. The developer must determine the appropriate resolution type, from those listed below, and updates the status and resolution type in the Production Defect Tracking Tool. Ownership of the defect then reverts back to Quality Assurance.
Quality Assurance Quality Assurance re-tests the defect in the test environment in order to verify that the

modifications made by development have corrected the defect, and have not caused any further problems.


If the re-testing demonstrates that the original defect is still present, the originator re-opens the original defect. The purpose of re-opening a defect that has been resolved, rather than creating a new defect, is to retain the defect history. The defect is sent back to the developer.

If the re-testing demonstrates that the original defect has now been corrected but another defect has been created, the originator closes the original defect as above, and opens a new defect.

Quality Assurance re-tests the defect in the production environment in order to verify that code has been successfully “built” and works correctly in the production system.

If the re-testing demonstrates that the original defect is still present, the designated QA team member re-opens the original defect and sends it back to the developer.

Notify the developer that the code can be move to the next environment when appropriate
If the designated QA team member successfully re-tests the defect and verifies that

the production system is now functioning as expected, the QA team member closes the defect in the Product Defect Tracking Tool and updates the following information:

  • Closed By
  • Date Closed Potential cause of production defect
    • user requirement
    • system requirement
    • development / code
    • unit test
    • integration test / system test
    • stress test
    • migration/turnover
    • data problem
    • database problem
    • interface / feed / vendor problem
    • operation/configuration problem
    • operation/capacity problem
  • Update and Track Status of Defects


QA Manager It is the responsibility of the QA Manager to ensure that all defects are entered, updated, and tracked through each activity. It is also the QA Manager’s responsibility to communicate back to Technical Support when a defect has been “closed”.

Notify Defect Reporter

Technical Support Technical Support notifies the defect reporter when a defect has been “Closed”.


File:SOP1061-03.gif



Forms

Form Description
Product Defect Reporting requirements See Appendix A


Exceptions

  • None at this time


Tools/Software/Technology Used

Tool Description

MS Word

Word Processing


MS Excel

Spreadsheet



Attachments


Related Standard Operating Procedures:

Personal tools
SDLC Forms