Bugs

Well documented bugs make everyone's life easier when it comes to fixing them

What are Bugs?

Bugs happen when released features do not work as intended. This could be from poorly written/tested code, missed edge cases or even poorly designed features.

Examples being:

• User unable to login

• Website banner is the wrong colour

• User unable to check out

• Website is down

• Website is taking too long to load

Where do Bugs Come From?

Bugs can be sourced from many places:

• Customer/user feedback

• Monitoring platforms

• Internal staff feedback

Ticket Template

Background

Include details to help the person the ticket is assigned to. This can include:

• Reporter/source of the bug

• Last known occurrence

• Impact of the bug

• Link to any monitoring tool showing the bug

Steps to Recreate

This should be as prescriptive as possible to ensure the person fixing the bug can recreate it. This should include:

• Exact step by step instructions to recreate the bug

• Screenshots and screen recordings are encouraged

• Link to any URLs where the bug occurs

Acceptance Criteria

Similar to the User Story:

Acceptance criteria are used to guide developers, designers and QA towards your vision for this feature. It is important to be as specific and exhaustive as possible so that all edge cases are considered when designing, developing and testing the feature.

Given [list of prerequisites], when [action to trigger the feature], then [expected outcomes/actions/feedback]

For the action to trigger the feature, try to keep it to one specific action that triggers the feature instead of multiple actions. For example:

• Use: "When the button is clicked"

• Don't use: "When the button is clicked and you are logged in"

This reduces the amount of confusion around what actually causes the newly developed feature to execute or occur.