Getting Started with Incident Tracking and Management in Software Testing (Sample Templates Included)

The focus of this article will be on how to identify and manage incidents in software evaluation using reference templates – termed as the “Incident Monitoring and Controlling Procedure”.

Wondering why someone would need to read this article after we have already shared abundant content on bug and defect tracking? We strive at first to elucidate how we differentiate an incident.

Understanding Incidents

Simply put, incidents during testing are events that should be rechecked.

The variance between the expected and actual results during testing is referred to as an error, defect, bug, problem, fault, or incident. Mostly, these terms are used interchangeably.

Incidents, however, come under a distinct category of issues that can stem from misconfiguration, compromised data, or even server crashes. Instances include full disk space, runtime errors, or service inaccessibility.

Software development issues, hardware usage errors, or service request mishaps can all contribute to incidents.

Contrasts Between Error, Defect, Bug and Incidents

1. Error: Unexpected system behavior resulting from human action. For instance, erroneous syntax, wrong value calculations, misinterpreting software requirements.
2. Defect: A term predominantly used by evaluators. When an issue is identified by a tester, it is referred to as a defect.
3. Bug: A term favored by developers. When identified defects are recognized by the developers, they are categorized as bugs. The bug-fixing process helps in resolving all the system bugs.
4. Incident: An unplanned disruption. It reflects a change in the activity status from working to failed, causing an unanticipated system response. In some cases, a single problem can lead to multiple incidents, which should ideally be addressed at the earliest.

Now, let’s delve into some associated terminologies:

1. Incident Repository: It’s a database encompassing crucial information related to system incidents. This data aids in generating incident reports inclusive of fields like date, expected and actual results, and the incident status.
2. Severity: It signifies the potential impact of an incident. Classifications are Major, Minor, Fatal, or Critical, each demanding immediate resolution.
3. Priority: It marks levels as per the severity of the incident and its influence on system functionality. It is tagged as High, Medium, Low, Very High, or Urgent/Immediate.
4. Incident Status: It indicates the current stage of incident management—tagged as New, In Progress, Resolved, or Closed.

What Does Incident Management Entail?

It involves the overall sequence starting from incident logging up to their resolution, thus aimed at restoring the business process or service back to normal as swiftly as possible.

Process for Incident Management

The broader procedure includes detection and resolution of incidents.

Being critical, the procedure assures an organized, effective incident resolution. By structuring the entire process, issues are likely to be resolved earlier.

Depicted below is a visual representation of the process, further explained in the subsequent sections.

#1. Detection and Logging of Incidents:
Tools-assisted testing, user feedback, infrastructure monitoring, etc., can help identify incidents.

Logging incident data entails recording:

• The exact time and day of occurrence.
• The incident type & title with a brief description.
• The incident logger’s name with a detailed description, including error codes whenever relevant.
• The assignee for the incident follow-up.
• The incident’s present status.
• Attachments consisting of technical discussions, decisions, and authorizations.

#2. Categorization and Prioritization:

Incidents can be grouped based on their type (software, hardware, service request) which facilitates more manageable analysis and reporting. Prioritization helps in deciding the sequence/order of incidents dealt based on their impact, severity and most significantly, the associated Risk Factor.

#3. Investigation and Analysis: In this stage, the problem is understood well for immediate rectification as well as for future prevention.

#4. Resolution and Restoration: Steps are taken to resolve the incident and restore system functionality to its previous state.

#5. Incident Closure: Once the resolution is confirmed and the system functions as before, the incident can be closed.

Incident Management System

Although incident management can be conducted manually or statically through spreadsheets, a tool-based approach is more systematic, dynamic, and effective.

Numerous Customer Support call centers utilize an incident management system for incident creation, updating, and resolution.

In demand Incident management tools:

Here are some well-known incident management tools suitable for tracking incidents besides bugs or defects:

#1. SiT! (Support Incident Tracking):

• Commonly known as the ‘Help Desk’ or ‘Support Ticket System’, Support Incident Tracker (SiT) is a free open-source web-based application that uses PHP and MySQL and supports all platforms.
• SiT permits users to email directly, attach files, and record every interaction in the incident log. It also factors in Service Level Agreements and highlights incidents that lag beyond them.

#2. JIRA:

JIRA, built by Atlassian, is also a commonly used proprietary incident management tool for tracking bugs, defects, and incidents. JIRA, a Java-based tool, is used widely for software and mobile apps. JIRA encompasses workflows, permissions, configurations, and various issue types. It also supports agile testing.

For a detailed understanding and step-by-step guides, you can visit: JIRA tutorial series.

#3. Incident Tracking System:
Incident Tracking System is a software used to supervise incidents, helping in pinpointing and analyzing incident causes and suitable solutions. It offers user-friendly interface with database support for recording and tracking incidents.

Incident Test Report

1. When a unique ID is assigned to each identified incident, a Test Incident Report is created in a defect repository. It documents all issues detected during varying test phases.
2. The standard format for a Test Incident Report is IEEE 829-1998, which is used to document each incident occurring during testing.

Brief of IEEE 829-1998 template:

=> Download the IEEE Incident Tracking Template right here.

Providing a concise description of the fields:

#1. Identifier: Refers to a unique ID assigned by the company to identify and locate an incident.

#2. Summary: Gives a brief summary of the incident. It includes enough details to understand associated facts such as references, related test procedures, software version, test scenarios, etc.

#3. Incident Description: Details of the incident:

• Inputs
• Expected Outcome
• Actual Outcome
• Repetition Attempt
• Abnormalities
• Date and Time
• Procedure Step
• Tester’s Name

The incident tracking report format may vary as per industry standards and business prerequisites.

An instance of a company-specific template:

=> Download the modified Incident Report Template right here.

On a Conclusive Note

This article clearly denotes that incident management does not deviate much from bug tracking. It successfully recreates the process with ISO norms and real-life examples.

On parting note, we’d like to caution you regarding getting fixated on the definitions of bug/defect/incident, since these terminologies are often used interchangeably in most companies. Some companies categorize inconsistencies in documentation as incidents, while others might consider environmental issues as incidents. Just as dialects differ regionally, so does QA technical terminology. Here, we present what is considered standard, not the rule—exceptions always exist.

Happy reading and learning!