Context
Thank you for your participation in testing the STA Soundscape App. The purpose of this document is to streamline the process of reporting bugs effectively.
The document outlines various essential components that need to be included in a bug report to help the development team identify and resolve them quickly.
Where do you send bug reports?
Please email your bug reports to support@scottishtecharmy.org
Structure of Bug report
The following points below detail how we would like you as a UAT tester to write a bug report.
Bug Title
Keep it short and specific.
Make sure it clearly summarises what the bug is. Having a clear title on your bug report makes it easier for the developer to find later on and merge any duplicates.
Examples:
Poor Example:
"I can't see the product when I add it, for some reason I try and it doesn't. WHY? Fix it asap."
Why is this a poor example:
It’s vague, aggressive, too wordy and demands a solution to be implemented.
Good Example :
“CART - New items added to cart do not appear”
Why is this a good example:
It helps developers instantly locate the issue (CART), it focuses on the technical problem.
When developers review it, they’ll be able to instantly assess the issue and move on to other elements of the bug report.
Summary
If your title isn’t enough, you can add a short report summary. In as few words as possible, include when and how the bug occurred.
Your title and description may also be used in searches, so make sure you include important keywords.
Examples:
Poor Example: "The other day I was trying to add stuff to a test and nothing showed up when I did that or clicked on the button."
Good Example: "On [DATE], I tried adding [PRODUCT] to the cart, nothing happened after clicking the 'add' button on the product overview webpage."
Poor Example: “The design text on the pricing page looks super weird and doesn't seem right. It shouldn't look that big and should be in a different colour.
Good Example: The headline text size and colour on the pricing page don't match the original designs.
Visual proof/screenshot
A screenshot or video can add a lot of value by getting your developers to see and understand the problem faster.
Example:
Expected vs. actual results
When you report a bug, take some time to explain to your developer what you expected to happen and what actually happened.
Example:
Expected result:”Item should be added to the cart when I click ADD”
Actual result:”Item does not appear in the cart”
Providing steps to reproduce the bug
Always assume that your developer has no idea about the bug you found—how do they reproduce it?
As always, keep it simple!
The steps to follow should be comprehensive, easy to understand, and short.
The goal of this step is for your developer to experience the bug first-hand.
Use a numbered list. If you’ve already managed to recreate the issue several times, you can include the reproducibility rate (example: 12/12 times bug reproduced).
Example:
- Search for product XYZ.
- Click on product XYZ in search results.
- Click on “Add to Cart” button.
- Go to cart.
You can add a short video recording or use a session replay tool—so the developer can watch you reproduce this new bug.
Environment
Mobile apps can behave very differently depending on the environment used.
It’s critical that the following information be included in any report you share:
Information required | Your answer |
Soundscape App Version |
|
iOS Version |
|
iOS Device Name |
|
Thank you – every bug you report makes Soundscape better for everyone.
Here is a copy of the page if you want to download this: