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 You Will Learn:
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.
Now, let’s look at a few related terms:
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 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:
#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 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):
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.
Outline of IEEE 829-1998 template is given below:
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
Incident Tracking report format can be changed according to industry standards and business requirements.
An example of one used in a company is:
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.