How to write a good incident report in software testing?

A good incident report is a technical document. We have few rules of thumb that can help you write a better incident report:

First, use a careful, attentive approach to execute your tests. You never know when you are going to find a problem. If you are pounding on the keyboard while gossiping with office mates or thinking about a movie you just saw, you might miss few of the strange behaviors.

You should also try to isolate the defect by making carefully chosen changes to the steps used to reproduce it. By isolating the defect it will help to guide the programmer in the challenging part of the system.

By writing the incident report it will help in increasing your own knowledge of how the system works – and how it fails.

Some test cases focus on boundary conditions, which may make it appear that a defect is not likely to happen frequently in practice. It is always a good idea to look for more generalized conditions that cause the failure to occur, rather than simply relying on the test case. This helps prevent the infamous incident report response, ‘No real user is ever going to do that.’ It also cuts down on the number of duplicate reports that get filed.

Irregular or infrequent symptoms are a fact of life for some defects and it’s always discouraging to have an incident report bounced back as ‘irreproducible’. So, it’s a good idea to try to reproduce symptoms when you see them. If a defect is irregular, we would still report it, but we would be sure to include as much information as possible, especially how many times we tried to reproduce it and how many times it did in fact occur.

As there is a lot of testing going on with the system during a test period, there are also lots of other test results available. Comparing an observed problem against other test results and known defects found is a good way to find and document additional information that the programmer is likely to find very useful. For example, you might check for similar symptoms observed with other defects, the same symptom observed with defects that were fixed in previous versions or similar (or different) results seen in tests that cover similar parts of the system.

Many readers of incident reports, especially the managers need to understand the priority and severity of the defect in order to know the impact of the problem in the project.

Most defect-tracking systems have a title or summary field in which the impact should also be mentioned. Choice of words matters a lot in incident reports. You should be clear and unambiguous. You should also be unbiased, neutral and fact-focused keeping in mind the testing-related interpersonal issues as discussed in Chapter 1.

Finally, keeping the report brief and to the point that will help to keep people’s attention and avoids the problem of losing them in the details.

As a last rule of thumb for incident reports, we recommend that you use a review process for all reports that are filed. It works if you have the lead tester review reports and we have also allowed testers – at least experienced ones – to review other tester’s reports. Reviews are proven quality assurance techniques and incident reports are important project deliverables.

Genislab Technologies