1Description of issue
Ensure that this is exactly what the user reported, although bear in mind that the user's description and knowledge of the system may well be different to your own.
Try and avoid including speculations of what might be the problem, unless the user is very, very knowledgeable about the system (i.e. to the same level as the product team!)
1.1What was the user doing when the issue occurred?
A step by step list of what the user was doing is important when trying to replicate the issue.
1.2What should the expected behaviour be?
This can be useful in cases where what the user considers to be a bug is actually how the system works (!)
2Is there a screenshot or video of the issue?
Screenshots are very helpful when trying to diagnose the source of an issue. If possible, displaying the browser developer tools while taking the screenshot of the issue allows any error messages to be seen.
Is the user logged in as a specific role (e.g. System Admin)?
4Browser and operating system
What browser and operating system were they using? This website allows you to send information about your browser to someone else: whatsmybrowser.org
5Is the issue repeatable?
Following the steps given by the user, can you reproduce this on a similar computer set up? What about on a different set up (e.g. browser or user role).
To assess priority of an issue, think about its frequency and impact.
Frequency: how often do users encounter the problem? All users, or some?
Impact: what affect does the issue have? Does it mean a main activity can't be completed?
Issues involving problems with security or data are highly likely to be critical bugs.
Try beSlick for free
beSlick embeds processes like these into your organisation, so it runs like clockwork.
Click 'Use template' and request a free trial - we'll help your teams get it right, every time.
Use this template on beSlick
Sign up for free today and add this template to your account.