Error report is a document that communicates a problem or a potential problem to the Motorway software support team.
In order fixing the error quickly the report must contain all the information necessary to convey the issue, its seriousness, severeness, evidence, steps to reproduce it, etc.
Error report is essential not only for relaying information about a malfunctioning itself but also to assign, track, and manage them for final closure. It is important to understand and differentiate errors and user’s wishes. That’s why it is crucial in first steps to answer the question is it not working or is it so because it is designed to work so? In the lattes case it could be a start to compile business need.
Addition to other relevant information error report should contain following:
Title should be short and clearly highlighting the error without any unnecessary information.
For example:
a) 404 on accessing sales report page as sales manager.
Comment: all is said without any useless information
b) sales manager Tom couldn’t access to last year’s sales report yesterday, but it was possible day before.
Comment: for a title it has too much irrelevant information. It can even mislead to the wrong questions is there a problem with Tom or the dates?
Description of an error is most important part of the report; therefore, it should contain as much relevant details as possible to help support team to narrow down the exact sequence of steps that are causing the issue. It is recommended to use short and clear sentences.
For example:
a) user logged in as a sales manager and choose menu “Reports”. When clicked on the sales report page, filters opened. Once filters were set and “Show report” button got clicked, 404 error appeared. By choosing other filter problem remained. Error appeared when logged in with dealer user.
Comment: description has required amount of information to reproduce the problem and understand that the problem doesn’t concern filters or user rights.
b) our colleague Tom logged in 09 AM this morning and nothing seemed to be working as it did yesterday.
Comment: only irrelevant information without any concrete error description to replicate.
It would be more comprehensive to use sequence of steps as a list with expected and actual result as a conclusion. With this method support team could identify and reproduce the problem faster.
For example:
Expected result: report should have been opened
Actual result: 404 not found error
Comment: example describes the error clearly by showing all the steps with details. Support team can follow these steps and reconstruct the situation for further analyse.
Avoid description in example below:
1. trying to get sales report
Expected result: report
Actual result: no report
Comment: relevant information is not provided about error, or the steps user tried to perform. Compared to the previous example it is unclear is this really an error, how it appeared, or how support team should be able to understand what exactly is not working.
Some software features might behave differently on a various operation system, devices, browsers, etc. Therefore, it is important to provide the information about environment where exactly the problem occurred.
For example:
a) Operation system macOS Big Sur v 11.7.9
Browser Safari version 16.6 (16615.3.12.11.3, 16615)
Device MacBook Pro Mid 2014 processor 2,6 GHz Dual-Core Intel Core i5
Comment: of course, user can’t list all the devices and OS’s, but it would be useful information for the support team.
b) Mozilla Firefox and Chrome
Comment: it might be helping but not in details.
Severity manages the issue in the perspective of importance. Severity gives estimation of how serious the problem is to the effective functioning of the software or business. Severity takes into consideration of affected scale and other required parameters.
As an example, it could be set up like that:
Similar to severity, priority sees the problem in the perspective of time. Also, priorities may differ from team-to-team but in purpose of internal analyse following approximate parameters should be set.
For example:
Severity and priority are similar criteria and from severity level the appropriate priority should be set. What can be highly severe in business-wise it might not be so in timewise.
For example:
a) getting Sales Report, 404 error occurs
Severity = medium
Priority = medium
Comment: report is only providing some help to sales manager and there are multiple workarounds, both severity and priority are medium here. In some cases, it can be also vice versa.
We do not recommend setting these values higher just in hope to get them solved faster. Support team will evaluate these internally for any required correction.
For faster managing and solving the issues, please always add screenshots, videos, photos if possible.
Compiled by Motorway Software
