SDLC SOP 1061 - Incident Tracking
From OpenSDLC
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
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 |
|---|---|
|
| |
| 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:
Defects recorded in the Production Defect Tracking Tool (SQA Manager) may have one of three statuses:
action to correct it has been taken by the responsible developer .
| |
| 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:
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:
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:
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:
| |
| 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 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:
| |
| 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”.
|
|
| |
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:
