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

In this article, we are going to learn in detail about the “Incident Tracking and management” Process. We will see how to track and manage incidents in Software Testing with sample templates.

You must be thinking- “STH has published a lot of content on defect/bug tracking, so how is this going to be different”? That is the reason why we have to look at what we mean by incident first.

Incident Tracking and Management

What is Incident

In simple words, incidents can be defined as an event encountered during testing that requires review.

While testing if the actual result varies from the expected result, it is referred to as a bug, defect, error, problem, fault, or incident. Most often, all of these terms are synonymous.

Incidents, however, are a special category of issues that might occur due to misconfiguration, corrupted data, server crashes, etc. Examples are Disk space full, error in execution (Runtime Error), service unavailable, etc.

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

Difference Between Errors, Defects, Bugs, and Incidents

1. Error: An action performed by a human that results in unexpected system behavior. E.g. incorrect syntax, improper calculation of values, misunderstanding of software
   requirements, etc.
2. Defect: This is a term usually used by testers. If the tester finds a mistake or problem then it is referred to as Defect.
3. Bug: Bug is the developer’s terminology. Once a defect found by a tester is accepted by the developer it is called a bug. The process of rectifying all bugs in the system is called Bug-Fixing.
4.  Incident: Incident is an unplanned interruption. When the operational status of any activity turns from working to failed and causes the system to behave in an unplanned manner, it is an incident. A problem can cause more than one incident which is to be resolved, preferably as soon as possible.

Now, let’s look at some of the related terms

1. Incident Repository: Incident Repository can be defined as a database that contains all the important and relevant data about all incidents occurring in the system. This information was subsequently used to create the incident report. It contains fields such as data, expected results, actual results, date and time, the status of the incident, etc.
2. Severity: The potential impact of the incident will decide its severity. This can be Major, Minor, Fatal, or Critical for immediate resolution.
3. Priority: Set according to severity and influence on the working status of the system. Values can be High, Medium, Low, Very High, or Urgent/Immediate.
4. Incident Status: The current state where handling the incident is. This can be New, In Progress, Resolved, and Closed.

What is Incident Management?

Incident management is a process for logging, recording, and resolving incidents as quickly as possible to restore business processes or services back to normal.

Recommended Incident Management Software – Salesforce

There is hardly a better tool out there that does incident tracking and management as well as Salesforce. The platform is capable of proactively seeking out a problem and presenting agents with the ability to resolve it before the issue worsens. The fact that it can integrate with platforms like Slack also makes incident handling and escalation quicker and considerably more efficient.

Features:

• Proactive Incident Detection.
• Streamline operations with real-time collaboration.
• Keep customers updated via multiple digital channels.
• Automate business processes using AI.
• Integrate with external systems for quick problem resolution.

Incident Management Process

Incident management is the overall process starting from logging incidents to resolving them.

This is a very critical process as this will ensure that the incidents get addressed in a systematic and effective manner. Also, by streamlining the entire process, there is a good chance that early fixing of the issues might happen.

The following is a diagrammatic representation of the process and we will discuss each stage in detail next.

#1) Incident Identification and Logging: Incident Identification is either done via testing (using tools or otherwise), user feedback, infrastructure monitoring, etc.

Logging an incident simply means recording the following info:

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

#2) Classification and Prioritization: Classification of incidents helps us partition them based on their type (software, hardware, service request, etc.) so it makes for easier reporting and analysis. Prioritisation helps to identify the order/priority of incidents to be handled. It depends on the impact, severity, and most importantly the Risk Factor.

#3) Investigation and Analysis: This step is to better understand the problem so we not only fix it right now but gather information to prevent it from re-occurrence.

#4) Resolution and Recovery: Steps are taken to remove the incident and bring the system back to its previous working condition.

#5) Incident Closure: The resolution is retested and in case the system is working as intended, the incident is closed.

Incident Management System

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

The incident management system is used by many Customer Support call centers to create updates 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 and web-based application which uses PHP and MySQL for and supports all platforms. It is also commonly known as a ‘Help Desk’ or ‘Support Ticket System’.
• Useful for sending emails directly from SiT, attaching files and recording every communication in the incident log. SiT is aware of the Service Level Agreements and incidents are flagged if they lie outside of them.

#2) JIRA

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

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

#3) Incident Tracking System

Incident tracking System is software used for tracking incidents. It helps to determine and analyze the root cause of incident along with suitable solutions. Incident Tracking System is easy to use and provides database support for tracking and recording the Incident.

Test Incident Report

1. A test incident report is an entry created in the defect repository with a unique ID for each incident encountered. The test incident report documents all issues found during the various phases of testing.
2. IEEE 829-1998 is the standard format for test incident reports which are used to document each incident that occurs during testing.

The outline of the IEEE 829-1998 template is given below:

=> Download IEEE Incident Tracking Template here.

The following is a brief explanation of the fields:

#1) Identifier: Specifies ID which is a unique and company-generated number to identify and locate an incident.

#2) Summary: Summarizes the incident in a concise way. Contains sufficient details to understand related facts viz. references, associated test procedures, version of the software, test cases, etc.

#3) Incident Description: Describes incident with the following details: Inputs

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

The Incident Tracking report format can be changed according to industry standards and business requirements.

An example of one used in a company is:

=> Download the modified Incident Report Template here.

Conclusion

As this article shows incident management is not very different from bug tracking, it is a wonderful recap of the process with some ISO standards and practical real-life templates attached.

One word of caution for all of you before ending this article is try not to be too attached to the definition of bug/defect/incident, etc because most companies do not differentiate between one term to the other.

So all of them are used synonymously for the majority of the time. Also, there are some companies that call their documentation inconsistencies incidents, others call environmental issues incidents. So you can see as the dialects change with regions, so does technical QA terminology. What we bring to you is the majority, not the norm – exceptions can always exist.

Hope you enjoyed reading this article. Feel free to post your thoughts, doubts and feedback in the comments section below. We would love to hear from you.