URL's on Bug Reports
Two mandatory URLs must be part of a bug form, yet, there is only one field called URL; why is that?
Indeed, the answer is straightforward, though it may cause some confusion at first.
So, where do these 2 URLs go? From top to button, the first URL goes in the field with the same name and must be filled as the placeholder text within the field instructs: ❝Provide the URL where the bug occurred❞.
This is mandatory information that only you will know since it is directly linked to the page where you've found the bug you're reporting.
The second URL is a common step in a test cycle for all testers. It allows access to the testing environment within the scope of the cycle.
This URL is under the ❝Overview❞ tab in the ❝Access❞ section and goes in the steps section, in the first one in the form of ❝Go to https://www.dummy.com/❞.
REMEMBER: The URL in the first step is the same for everyone; the URL is the one only you can know.
TL's Requests
Information requests, what's that? Sometimes additional information is needed to identify a bug, like a screen size or the device model used; in such cases, customers and team leaders could send an information request.
However, numerous bug reports get rejected because, after 24 hours, they were never seen or were unattended, causing an easily avoidable rejection reason!
Here’s an example of what it looks like when a request is not addressed in your bug report:
This is why today we're sharing ❝What to do when you receive an Information Request❞:
You have 24 hours to respond to the Information request.
You should provide only the requested information.
You shouldn't submit a comment after you update the bug report because TL will get the notification from the system. There is no point in pushing more notifications for the same ticket.
Use the same device to reproduce the bug as you did with the original bug report attachment(s).
If you are requested to record the bug with an external camera, make sure that your movements are easily visible and that the attachment follows the general rules about bug report attachments.
If you are no longer able to reproduce the bug, leave a comment under your bug report for your TL or the customer. It is better to inform them about it than to wait until the time runs out.
Never leave comments like "OK. I'll do it later." because you might end up with a warning.
Never leave inappropriate comments. Be professional.
To ensure that you don’t miss any requests, make sure to activate notifications for all ❝New bug comment❞ alerts. Here’s how to do it:
ALERT: Every rejection harms your Quality Score, some more than others, but it's always better to try to avoid them, especially this one that is only checking your notifications or emails on time.
Reproduction Attachements
When a bug has already been reported, you can't submit it again. Still, you can provide a reproduction, a fundamental part of software development, because they help identify affected environments and the bug’s severity.
To reproduce a bug, follow the original tester's steps. If successful, it's a positive reproduction; if not, it's negative. Screencasts are required for reproductions, and there are specific rules to follow:
A screencast is required.
Your screencast should be no longer than 15 seconds. Showing the action that triggers the bug is enough in most cases.
Only in rare cases, if you cannot show the bug-triggering action within 15 seconds (e.g. when the page is loading endlessly), your screencast may be longer but not longer than the screencast from the original tester.
Your screencast must include the current date and the URL bar when testing a website.
When reproducing an app crash, upload a crash log file in addition to your reproduction screencast. Your screencast has to correspond to the attached crash log, i.e. timings must be coherent.
Testers are only able to perform one task at a time. The ❝Start Reproduction❞ button will only be visible for particular reports that have not yet been reviewed and have not exceeded their maximum number of reproductions.
Sometimes, we may not want to record our entire device’s screen due to a short screencast or concerns about private information in our browser. However, we may forget these guidelines and submit videos that do not adhere to them.
A great way to improve our screencasting skills is to observe others. To help you enhance your recording abilities, here’s a screencast to watch and learn from:
Can you identify any issues with this screencast? What essential information should be included? Take your time to review the video and avoid similar mistakes carefully.
HINT: The length of the GIF is precisely 15 seconds, so this is not what is wrong.