Each bug must be documented with at least one attachment. With your attachment(s), you provide evidence that the bug occurs on your device, operating system, and/or browser.
Note: Attachments do NOT replace written information in your report. Attachments are a visualization of the problem and serve as proof.
Screenshot or screencast?
In general, functional bugs require a screencast to be illustrated properly and effectively. Unless the instructions or the team leader asks for specific attachments, use the following rule of thumb to determine whether a screenshot or a screencast is required for your bug:
Whenever an action is required to trigger a bug or when a process needs to be illustrated, upload a screencast. Screenshots as static images are snapshots and cannot illustrate the root cause. Functional bugs will always require a screencast for that reason.
When the nature of a bug is static, e.g. for static GUI problems, a screenshot is enough and a better visualization than a video. Screenshots should be enough for Content or Visual issues.
General attachment requirements
New attachments have to be created for every bug report or reproduction.
It is prohibited to copy attachments from other bug reports or reproductions.
Attachments must show all relevant bug information to serve as proof.
All relevant information must be displayed in English (or optional German if the bug report language is German), e.g. the date, time system information, and error messages.
You should select only one device or browser when you are reporting the bug, and upload only attachment for it. If you are able to reproduce the bug in other devices or browsers, please mention this in your Actual result.
Don’t show any information about other Test IO customers that can be related to Test IO (e.g. invitation emails or browser tab names). Showing installed apps of other customers is permitted.
Don't show any personal information or unprofessional data such as pictures, videos or autocorrect bad word suggestions. Remember your attachments will be available to other testers, to the test IO staff and to the customer so be careful with what you're showing on them.
For website tests, the URL field must be visible on attachments.
The resolution must be high enough so that the text and elements can be easily identified.
Please always record your whole screen.
A crash log is mandatory for bug reports and positive reproductions of app crashes. The video that documents the crash has to correspond to the attached crash log, i.e. timings must be coherent.
Date and Time specific rules:
The current date and time must be visible in the attachments.
When proving a bug via a screenshot on a mobile device, a second screenshot showing the date and time must be uploaded (battery charge and time must match with the first screenshot).
The date can be in any common date format, e.g. DD/MM or MM/DD, in English (or optional German if the bug report language is German).
Time should be in a 24-hour clock, or if you use a 12-hour clock, please make sure that you use AM/PM format.
By displaying the current date on your attachment, you prove that you recorded it on that date. The following list suggests where to find the date:
Windows: Displaying the taskbar or blending in the calendar
Mac: Displaying the calendar icon in the Dock or the menu bar
iOS & Android: Swipe down the notification centre at the beginning of your recording.
Further information: How-to-Geek.
What needs to be included in a screenshot?
Screenshot-specific rules:
The screenshot has to be in JPG or PNG file format.
Highlight the bug on your screenshot.
We recommend recording tools and best practices in the following article: Screenshots
What needs to be included in a screencast?
Screencasts should be as short as possible but as long as necessary. This means that you should leave out steps that do not cause the bug. For example, when the “Add to cart” button on a product detail page of a webshop is defective, it is generally irrelevant how you navigated through the webshop to reach the product detail page. The last navigational step, the step that triggers the bug, and the bug itself are usually relevant.
Example 1: Bug on the website, tested on a Desktop device
Steps to produce a screencast:
Go to the page where the bug occurs.
Start your recording.
Refresh the page.
Perform the action that triggers the bug.
Wait until the bug occurs.
Stop the recording.
Example 2: Bug in the app, tested on the mobile device
Steps to produce the screencast:
Run the app and go to the page where only one more navigational step is needed to reach the page where the bug occurs.
Start your recording.
Swipe down the notification centre to show the current date for a couple of seconds.
Perform the last navigational step to reach the right page.
Perform the action that triggers the bug.
Wait until the bug occurs.
Stop the recording.
Team leaders might send you an information request asking for an external or additional recording. This is done to gain a better understanding of the bug or when in doubt due to the bug being non-reproducible.
Screencast-specific rules:
Screencasts must have the MP4 file format.
The maximum size of the attachment is 25 MB.
The maximum time for a screencast is 60 seconds for Bug Reports unless your bug requires showing a loading process or long necessary manual inputs.
The maximum time for a screencast is 15 seconds for Reproductions and User Stories attachments since you must only show the last action that triggered the bug.
Your clicks/taps/touches and the mouse icon must be visible (only required for Android and desktop recordings).
Make your recording in one go. You should not pause, nor cut parts in the middle. If your screencast is too long and you want to edit it, only cut the beginning or the end of the file.
Increasing the speed of your screencast is not allowed. If you recorded more than the allowed time, please check if you did not show unnecessary steps of your screencast.
Don't record any noise (baby screaming, conversations, TV, music, pets, etc.).
We recommend recording tools and best practices in the following article: Screencasts
Screencast-specific rules for Streaming devices:
Always record your whole TV Screen.
Screencast should have high resolution and good quality.
The ambient light should not be dark.
Your TV Remote must be visible in the screencast. Also, the remote must be fully and clearly visible.
The current date and time must be shown in the attachment. You can show the current date on the TV itself, or on some external device such as a PC, phone, or tablet.
For Bug Reports, the maximum time for a screencast is 60 seconds, while for Bug Reproductions and User Story Attachments, the maximum time is 15 seconds.
Don't record any noise (baby screaming, conversations, TV, music, pets, etc.).
Screencast should always look professional, do not record your legs, messy TV stand, or similar.
Blurring Out Private Information on Attachments
To protect your private information, such as bookmarks, account names, or stored emails, from being visible on browser tabs, you can follow this simple technique of blurring them out. However, for a more efficient bug-reporting process, it’s recommended to use a dedicated browser window for testing purposes, as demonstrated in the example below that shows no unnecessary browser tabs open or visible bookmarks.
If you need to include private information in your attachments but don’t want it to be visible, you can follow this example to conceal it professionally; note that the browser tabs' names that might show email addresses, usernames, and bookmarks are hidden.
It’s important to note that the URL should still be visible, and the website elements should not be obstructed.
For professional reasons, it’s crucial to avoid hand-drawn or sketchy methods when covering information on your attachments, as shown in the example below:
