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

In today’s article we are going to learn all about the “Incident Tracking and management” Process – How to track and manage incidents in Software Testing with sample templates.

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

What is Incident?

Incidents can be defined in simple words as an event encountered during testing that requires review.

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

Incidents however are a special category of issue that might occur due to misconfiguration, corrupted data or server crash etc. Examples are: Disk spaces full, error in execution (Runtime Error), service unavailable etc.

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

Difference between Error, Defect, Bug and Incidents:

1. Error: An action performed by human that result in unexpected system behavior.
   g.; incorrect syntax, improper calculation of values, misunderstanding of software
   requirement etc.
2. Defect: This is a term usually used by testers. When tester finds a mistake or problem then it is referred to as Defect.
3. Bug: Bug is developer’s terminology. Once a defect found by a tester is accepted by 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 incidents which are to be resolved, preferably as soon as possible.

Now, let’s look at a few 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 is subsequently used to create the incident report. It contains fields such as data, expected results, actual result, date and time , status of incident etc.
2. Severity: The potential impact of the incident will decide their severity. It 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 at. It can be New, In Progress, Resolved and Closed.

What is Incident Management?

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

Incident Management Process

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

It is a very critical process as this will ensure that the incidents get addressed is 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 type and brief description
• Name of the person who logged the incident and more detailed description
  with 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 us partition them based on their type (software, hardware, service request, etc.) so it makes for easier reporting and analysis. Prioritization 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 for preventing 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 spread sheets but it is much more effective, dynamic and systematic when done via a tool.

An incident management system is used 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 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 to send emails directly from SiT, attach files and record every communication in the incident log. SiT is aware of Service Level Agreements and incidents are flagged if they are lying 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 scheme involves workflows, permissions, configurations, issue types etc. JIRA also supports agile testing.

For more information and tutorial, 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 solution. Incident Tracking System is easy to use and provides database support for tracking and recording the Incident.

Test Incident Report:

1. Test incident report is an entry created in defect repository with 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 report which is used to document each incident that occurs while testing.

Outline of 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 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 following details:Inputs

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

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

An example of one used in a company is:

=> Download modified Incident Report Template here.

Conclusion:

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

Another word of caution that we want to leave you all with before ending this article is that- 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 as incidents, other call environment issues as incidents- so you see, as the dialects change with regions, so does technical QA terminology. What we bring to you is the majority, not the norm- exceptions always exist.

Happy reading!