Incident report can be defined as a written description of an incident observed during testing. To understand better, let’s start with what an ‘incident’ is.
Incident in a software testing can be defined as a variation or deviation observed in system behavior from what is expected. It can be a deviation from a functional requirement or from the environment setup. Very often an incident is referred as a defect or a bug, but it is not always the case. Incident is basically any unexpected behavior or response from software that requires investigation. Let’s study the difference between the two to understand better.
| S.No. | Incident | Defect |
| 1 | Occurrence of any unexpected behavior while testing. | When actual behavior does not match expected behavior. |
| 2 | It might or might not be required to fix it, depending on whether it is a defect or just a mistake or some environmental issue. | It needs to be fixed. |
As mentioned in the table, incident needs to be investigated and based on the investigation the incident can be promoted to a defect. Most often it turns out to be a defect but sometimes it might occur due to different factors such as
- Human mistake.
- Missing or Obscure documented requirement.
- Environment issue such as no response from back-end server causing intermittent unexpected behavior or error.
Now that we understand incident let’s move to incident report. When an incident is observed a descriptive report is prepared, logged and tracked. A software may have many incidents, depending on its size. For a small software up to 100 incidents might be reported. It is difficult to keep track of all of them in an unorganized manner. So a report comes in handy to differentiate and manage the incidents. Some of the benefits of having an incident report are as follow:
- It is easy to manage and track the incidents.
- It provide a detailed information to the developer or a third team to help in understanding the problem and providing the solution for it.
- It helps in keeping or storing the records for future reference while creating regression test suite.
- A report can later help in categorizing the defects to help in root cause analysis and in finding out the most problematic areas.
- There might be multiple testers testing the software. It is possible that more than one person notice the same incident. An incident report helps the tester to avoid reporting a duplicate issue as he can check the records before filing the incident.
How to write a good incident report:
Here are some tips to write a good report:
- Summary: Keep the summary of the report concise and to the point. The main issue should be clear in the summary and it should provide a short overview of the problem.
- Description : It should contain details regarding incident such as:
- of test cases impacted
- Application under test
- Build of the software
- Status of the incident – It can be ‘New’, when filed, ‘Assigned’, when it is assigned to a team for investigation or ‘Fixed’, if incident has been promoted to a defect and has been fixed. It is changed many times throughout the lifecycle of incident.
- Name of the project
- Date – It helps in keeping the track of age and the time it took to resolve the incident
- Name of the tester etc.
- Test data: Mentioning the test data is very crucial. As sometimes the defect may be due to a particular value entered in the software. It should not be skipped.
- Severity: It has a great significance in an incident report. It indicates the how serious or intense the defect is, in terms of the software requirement. Suppose a button has been added in an application as per a functional requirement. If that button does not display during testing then the severity of the incident should be high. But if the position of button is not right then it would be a medium or low priority incident.
- Priority: It is another very important aspect of a defect. It indicates how fast the defect should be resolved. An incident that is impacting more no. of test cases should have a high priority. An incident reported for display of the application for ex, lines not aligned should have a low priority.
- Steps used: Keep track of what you are doing while testing. While logging an incident, it is important to provide step by step detail of how the point of incident was reached. Sometimes a developer returns the incident as “Not Reproducible” due to the ambiguous steps. This is time consuming. So, it is a good practice to provide detailed and clear steps used.
- Results: Results have two categories. Both should be very clear as it helps the reader to understand the variation or deviation in system behavior form the expected .
Actual – It is the observed result. It is what is observed during testing.
Expected – It is what the tester is expecting to see.
- Assigned to: It is the field that is populated with the team to whom the incident should be assigned to. It might be for initial investigation, to get extra inputs or to fix the defect. Like Status of the incident, this field is also changed multiple times throughout the lifecycle of the incident.
- Proof: It is the proof of the behavior observed. It is generally the screenshot of the screen with the unexpected behavior.
- Identification Number/Incident ID: It is provided by the software used for tracking incidents and is used to uniquely identify it.
Incident Management Tools:
There are many tools to manage the incidents or defects in a Software testing lifecycle. An incident management software should possess the features for providing a detailed description of defect such as:
- Comment section for discussion
- History
- Attachment section to attach proof
- Fields like Summary, Description, Severity, Priority, Assigned to, Defect Age, Status, Tester name, Identification Number etc.
Some of the Incident/Defect Management software are listed below:
- IBM Rational Clear Quest (RCQ)
- HP Application Lifecycle Management (ALM)/ Quality center (QC)
- JIRA
- BugHost
- Bugzilla etc.
There are many test management software which can be synced with these tools to manage both test cases and incident and an incident can be directly synced with the test cases it is impacting. For ex, IBM RCQ can be synced with IBM Rational Functional Tester (RFT).
So incident in a software can be summarized as an unexpected behavior which may or may not be a defect and requires investigation by relevant teams. An incident report is a detailed description of the incident observed and contains data like Summary, Steps Used, Priority, Severity, No. of Test Cases Impacted, Status, Assigned To etc. An incident report is important as it helps in keeping track of the incidents and it provides information to concerned people. Be it a developer fixing the defect, or a tester re-testing it. Incident Reports are managed using different tools available in market such as HP ALM, JIRA etc.
⇓ Subscribe Us ⇓
If you are not regular reader of this website then highly recommends you to Sign up for our free email newsletter!! Sign up just providing your email address below:
Happy Testing!!!