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

In this 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.

Incident Tracking and Management in Software Testing

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 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 issue that might occur due to misconfiguration, corrupted data, server crashes, etc. Examples are Disk spaces 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 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 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

Salesforce Logo

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 make incident handling and escalation quicker and considerably more efficient.


  • 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.

Incident management Process

#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)

Incident tracking tool 1

  • 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, attach files and record every communication in the incident log. SiT is aware of Service Level Agreements and incidents are flagged if they lie outside of them.

#2) JIRA

Incident tracking tool 2
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. 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.


As this article shows incident management is not very different from bug tracking, this will be a wonderful recap of the process with some ISO standards 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 incidents, others call environment issues 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!

Recommended Reading

12 thoughts on “Getting Started with Incident Tracking and Management in Software Testing (Sample Templates Included)”

  1. Hi,

    Nice Article!!!

    I have a little confusion here, Defect is also an unplanned event.

    You meant the environment factors or performance degradation issues can be called as Incidents? Because these can occur at anytime?


    • Testing scenarios considers all these terms equally.

      But the basic difference is that The Defect is the thing which goes against requirement specifications mostly related to Functionality of the system where on other hand Incident is an event which occurs unexpectedly regardless of requirement specifications.

      Examples given in the article such as not enough disk space, misconfiguration etc. are the thing that are not been mentioned in requirement specifications given by the end user or client we say, these are the things that causes an Incident should be taken in consideration by the development team

  2. Hi Can you share more free tools for this?

    • Will try to update and revert back on it

  3. nice getting started article

  4. Can we also say that if any, any unexpected low priority behaviour, which can lead to a major defect, is known as Incident?

    What exactly a Incident?

    • Hope you got the answer from above comment. But if any unexpected behaviour causes major defect then the priority should be high only, because priority is depended on severity of the defect.

  5. Good Explanation!!!



  7. Thanks for the great article and follow up discussion. what is the recommendation for Test execution process? Durign execution, if a tester identifies an issue, should it be logged as Defect or an incident? Or depending on the nature of the issue, should it be classified?

  8. Of course, depending on the nature of the issue it should be categorized.

  9. Hi,

    I have been downloading the incident dumps from service now in excel and want to integrate to HP ALM with macros .Could you please suggest a way for this?


Leave a Comment