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

The topic we will be covering in this article is the “Process of Incident Tracking and Management” – How to trace and control incidents in Software Testing using example templates.

Are you pondering – “STH has posted a lot of content on defect/bug tracking, so how will this be dissimilar”? That is precisely why we need to examine what we specify as an incident first.

Definition of Incident

In simple terms, incidents are considered events encountered during testing that necessitate review.

When the actual result deviates from the anticipated result during testing, it is referred to as a bug, defect, error, problem, fault, or an incident. In most cases, these terms are essentially interchangeable.

However, incidents are a distinct category of problems that may arise as a result of misconfiguration, corrupted data, or server crashes, etc. Examples include: disk space reaching full capacity, execution errors (Runtime Errors), service unavailability, etc.

Incidents can also occur due to issues in software development, hardware usage, or service request errors.

Disparity Between Error, Defect, Bug and Incidents

1. Error: An error is an action performed by a human that results in unexpected system behavior.
   e.g.; incorrect syntax, improper value calculations, misinterpretation of software
   requirements, etc.
2. Defect: This term is commonly used by testers. When a tester discovers a mistake or problem, it is referred to as a defect.
3. Bug: Bug is a term used by developers. Once a tester identifies a defect and it is accepted by the developer, it is then classified as a bug. The process of fixing all bugs in the system is known as Bug-Fixing.
4.  Incident: An incident is an unplanned interruption. When the operational status of any activity changes from working to failed and causes the system to behave unexpectedly, it is considered an incident. A problem can cause multiple incidents that need to be resolved promptly, if possible.

Now, let’s explore a few related terms:

1. Incident Repository: An Incident Repository can be defined as a database that contains all the vital and pertinent data about all incidents occurring in the system. This information is later employed to generate the incident report. It includes fields such as date, expected results, actual result, date and time, status of the incident, etc.
2. Severity: The severity of an incident is determined by its potential impact. It can be categorized as Major, Minor, Fatal, or Critical, each requiring immediate resolution.
3. Priority: Prioritization is based on the severity of the incident and its influence on the functioning status of the system. The priority can be designated as High, Medium, Low, Very High, or Urgent/Immediate.
4. Incident Status: The current stage of incident handling. It can be categorized as New, In Progress, Resolved, or Closed.

What is Incident Management?

Incident management is a process for logging, recording, and resolving incidents as rapidly as possible to restore the business process or service back to normal.

Methodology for Incident Management

Incident management encompasses the overall process, which starts from logging incidents to resolving them.

Due to its criticality, this process ensures that incidents are addressed in a methodical and effective manner. Moreover, by streamlining the entire process, there is a greater likelihood of early resolution of issues.

The following diagram provides an illustrative representation of the process, which will be discussed in detail in the ensuing sections.

#1. Incident Identification and Logging:
Incident Identification can be done through testing (using tools or otherwise), user feedback, or infrastructure monitoring, among other methods.

Logging an incident involves simply recording the following information:

• Exact/Appropriate date and time of occurrence.
• Incident title along with type and a brief description.
• Name of the person who logged the incident and a more detailed description
  including error codes when applicable.
• Details of the person assigned to the incident for follow-up.
• Current Status of the incident.
• Attachments including technical discussions, decisions, and approvals.

#2. Classification and Prioritization:

Classification of incidents helps in categorizing them based on their type (software, hardware, service request, etc.), enabling easier reporting and analysis. Prioritization aids in determining the order/priority of incidents to be handled based on their impact, severity, and most importantly, the Risk Factor.

#3. Investigation and Analysis: This step entails gaining a better understanding of the problem at hand, not only to rectify it immediately but also to gather information for future prevention.

#4. Resolution and Recovery: Actions are taken to address the incident and restore the system to its previous working condition.

#5. Incident Closure: The resolution is tested, and if the system is functioning as intended, the incident is closed.

Incident Management System

Incident management can be done manually or statically using spreadsheets, but it is much more effective, dynamic, and systematic when implemented through a tool.

An incident management system is utilized by many Customer Support call centers to create, update, and resolve incidents.

Popular Incident management tools:

Some popular incident management tools that can be used for tracking incidents in addition to bugs or defects are:

#1. SiT! (Support Incident Tracking):

• Support Incident Tracker (SiT) is a Free Open Source web-based application that uses PHP and MySQL and supports all platforms. It is also commonly known as a ‘Help Desk’ or ‘Support Ticket System’.
• SiT allows users to send emails directly from the system, attach files, and record every communication in the incident log. It also takes into account Service Level Agreements and flags incidents that fall outside of them.

#2. JIRA:

JIRA is also a popular proprietary incident management tool developed by Atlassian used for bug, defect, or incident tracking. It is a Java-based tool used for software and mobile apps. JIRA involves workflows, permissions, configurations, issue types, etc. JIRA also supports agile testing.

For more information and tutorials, please visit: JIRA tutorials series.

#3. Incident Tracking System:
Incident Tracking System is software used to track incidents. It helps determine and analyze the root cause of incidents along with suitable solutions. Incident Tracking System is user-friendly and provides database support for tracking and recording incidents.

Report of Test Incidents

1. A Test Incident Report is created in a defect repository with a unique ID assigned to each encountered incident. The Test Incident Report documents all issues identified during various testing phases.
2. IEEE 829-1998 is the standard format for a Test Incident Report, which is used to document each incident that occurs during testing.

Outline of IEEE 829-1998 template:

=> Download the IEEE Incident Tracking Template here.

The following provides a brief explanation of the fields:

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

#2. Summary: Provides a concise summary of the incident. Contains sufficient details to understand related facts such as references, associated test procedures, software version, test cases, etc.

#3. Incident Description: Describes the incident with the following details:

• Inputs
• Expected Result
• Actual Result
• Attempt to repeat
• Anomalies
• Date and Time
• Procedure Step
• Tester’s Name

The format of the Incident Tracking report can be modified based on industry standards and business requirements.

An example of a template used in a company is:

=> Download the modified Incident Report Template here.

In Conclusion

This article has demonstrated that incident management is not significantly different from bug tracking. It serves as an excellent recap of the process, supplemented with ISO standards and practical real-life templates.

We would like to leave you with a cautionary note before concluding this article – try not to get too attached to the definitions of bug/defect/incident, as most companies do not distinguish between these terms. They are often used interchangeably. Furthermore, certain companies label documentation inconsistencies as incidents, while others consider environmental issues as incidents. As regional dialects differ, so do technical QA terminologies. What we present is the majority, not the norm – exceptions always exist.

Happy reading!