Session 6 of Module 5: Incident Management

Overview

• Topics Covered:
  • Definition of incidents
  • What is incident management
  • What are incident reports and how to write them
  • Incident or defect lifecycle

What Are Incidents?

• Definition: Any situation where the system exhibits questionable behavior.
• When it occurs: During testing or in production environment by end users.
• Identification: When actual results vary from expected results.
• Causes:
  • Test environment issues
  • Developer code issues
  • Test data issues
  • Hardware issues
  • Invalid expected results
  • Tester mistakes
• Defect/Bug: An incident is considered a defect or bug only when the root cause is a problem with the item being tested.

Incident Reports

• Description: Contains a description of the questionable behavior.
• Purpose:
  • Provides clear goals
  • Offers information to team members
  • Facilitates analysis of incident data
  • Helps improve the test process

How to Write Good Incident Reports

• Key Points:
  • Be attentive while running tests to catch incidents
  • Reproduce intermittent issues and add detailed information
  • Isolate issues by changing reproduction steps
  • Mention the impact of issues in the report
  • Use clear, unambiguous, and neutral language
  • Keep reports concise and to the point
  • Have reports reviewed by lead or experienced testers

Defect Detection Percentage (DDP)

• Definition: Compares field defects with test defects.
• Importance: Measures effectiveness of the test process.
• Formula:
  • DDP = (Defects found during testing) / (Defects found during testing + Defects found in the field)
• Interpretation:
  • DDP = 1 (Most effective test process)
  • DDP < 1 (Need to improve the test process)

Contents of an Incident Report

• Summary: Overview of the incident
• Steps to Reproduce: Detailed reproduction steps
• Expected and Actual Results: Clearly defined differences
• Software Version: Version in which incident was found
• Project Phase: Phase of the project where incident was discovered (e.g., functional testing, system testing, user acceptance testing, maintenance)
• Test Case Reference: Specific test case causing the incident
• Reference Documents: Links to requirements or other relevant documents
• Impact: The incident's impact on the software project

IEEE 829 Standard Test Incident Report Template

• Components:
  • Test Incident Report Identifier (auto-generated by tools)
  • Summary of the incident
  • Incident description (inputs, expected results, actual results, anomalies, date & time)
  • Steps to reproduce
  • Test environment
  • Attempts to repeat
  • Testers and observers
  • Impact
• Customization: Organizations may modify this template per their needs.

Incident/Defect Life Cycle

• States and Flow:
  1. Opened: Incident is logged and analyzed for validity
  2. Assigned: Assigned to developer
  3. Fixed: Developer addresses the issue
  4. Reassigned: Sent back to tester for verification
  5. Closed: If verified, the issue is closed
  6. Reopened: If verification fails, the issue is reopened
  7. Deferred: If not critical or cannot be addressed in the current release, the issue is deferred for later
  8. Rejected: If deemed invalid or not a problem
• Cycle Repeats: Deferred incidents are revisited in future releases.

Conclusion

• Topics Reviewed:
  • Definition and management of incidents
  • Writing effective incident reports
  • Essential contents of incident reports
  • Incident/defect lifecycle