4. Correct Attachments: An often overlooked aspect of bug reporting

In this chapter, we will discuss the importance of attachments to any issue, and of course, how to create quality reports.

A bug attachment is any form of visual proof that you can add in order to show your bug. In general, attachments come in 3 forms: images, video, and logs. 

90% of all attachments you are going to produce will be videos because any functionality issue will require a video detailing the steps required to reproduce the bug. And because by “functionality” we understand any bug that requires the user to perform actions inside the app, functionality bugs are the most numerous.

The only issues that do not explicitly require a video are very simple display issues like spill-outs and overlaps that can be shown in a single image. 

The last category involves logs that are required for crashes, clean restarts, memory issues, continuous loading, or connectivity problems.

Let’s go through each of them:

• Video guidelines:

Your video should be clear and all the actions performed in it should be easy to understand. We do not expect you to upload ultra-high definition videos, but the video should also not look like it was made on a toaster. We also advise you to be careful when compressing the video to reduce its size. We do not penalize testers for trying to compress their videos to save space but the screen should still be clearly visible. 

As a general rule, you should avoid your video being blurry or pixelated to the point where details are no longer clear.

We prefer videos made with screen capture tools as opposed to videos made with one device filming another. For both objective and professional reasons, the videos made with screen capture tools have better quality and look better than a shaky hand-held film. 

Please do not film your videos using a secondary device like another phone, or computer camera unless there is absolutely no other way to perform a reliable screen capture. The only acceptable exception is when the test is performed on a very old or damaged device that is not capable of using a recording app. If that is the case please specify this in the bug report’s description and this information will be taken into account. Otherwise, you risk your issue being rejected.

While discussing screen capture tools we suggest you use the iOS in-built screen recorder (tutorial here: https://support.apple.com/en-us/HT207935), the free Mobizen app for Android, and the Bandicam app for Windows. But feel free to use any app you personally prefer as long as the results are a good quality video with no unpleasant watermarks or any lag issues.

We strongly encourage you to use the AssistiveTouch feature when capturing a screen recording. When the “Touch” function is active anyone seeing your video can clearly understand what actions you took and what buttons you tapped or did not tap. This can greatly improve your chances of a bug being accepted as there will be no doubt regarding the validity of your claim. 

Unless the bug you are reporting is an audio bug, then the video should have absolutely no sound. Video attachments that have unnecessary audio will usually be rejected by the moderators. Audio is easy to exclude when performing a screen recording by setting the option of ‘no audio’ in the settings of the app you are using to record. There is no excuse for any sound, including regular system sounds, if they are not directly pertinent to your bug.

Your video should contain the entire screen, including the system bar. This shows us what kind of connectivity you are using (WiFi or Mobile Data) if you have any VPN active or any other location modifying the app.

In case the bug report is about loading or network connection problems the video must always contain an internet speed test performed in the same video as the bug report after the issue is successfully reproduced.

Do not have any personal or offensive information displayed on the screen. Please remember that when you perform a test on your device you should conduct yourself in a professional manner. We understand that most of you do not have dedicated test devices and are using your own personal devices. We do not in any way hold that against you, but we do require you to respect the rules set out for you. 

So we find it to be a good idea if you stop any non-test notifications during the video, as well as prevent incoming calls, messages, or notes with personal data displayed on the screen. It is also a good idea to close all other non-test apps while performing the video and having a neutral non-offensive wallpaper/background. Personal pictures should also not be used when uploading images to an app, and you should be careful to not show graphic/vulgar content in your device’s memory or open in a browser that you accidentally multitask to and from.

In case you have to record any personal information as part of a Test Case execution flow (i.e. for a Test Case that requires registration/new account creation), we encourage and recommend censoring, blurring, or covering any personal information that is visible for the duration within such videos.

Also, make sure you are not recording any internal documents, such as Test Case execution document, Bug Tracker, Tester Spec, Test invitation email, etc. These should never be part of any attachments.

Please always double-check your video before uploading it. A good standard practice would be to give the video the name or ID of your bug so you do not accidentally upload the wrong video. The double-check is also useful for you to notice any possible sensitive or incorrect information that you might have overlooked when reproducing the bug.

• Image guidelines:

As with a video, an image should be clear and understandable. The quality of the image should never be so low as to not easily distinguish individual words or buttons.

While we do encourage you to upload a video for most of the issues you might submit, there are many instances when an image is also very useful alongside the video. The best example of this would be when an error message is received inside the app, adding a PrintScreen of the error message body is very useful for the moderator to quickly and easily review your bug report and assess its value.

Images are best attached to a bug report where there is either a simple display or text issue like spill-outs, overlaps, bad translations, misspelled words, text or graphical element placeholders, etc.

A good image attachment should always point towards the issue it is trying to show. Adding a visual indicator that points towards the issue is a fantastic way to show the issue you found. Problematic visual elements can sometimes be hard to spot at first glance, and any aspiring tester should always submit professional results. A simple arrow or a bar underlying the problem should always be added to an image, even when the problem seems self-evident.

Just like the video, your image should contain the entire screen, detailing all the elements present.

• Log guidelines:

Crash Logs, Memory logs, Charles Logs, and many other forms of logs are all basically data files containing raw information about the apps you are testing.

Information about how to collect a log will always be available in the Tester Spec Document which you should read and familiarize yourself with before every test.

Obtaining logs may seem overwhelming the first time you try, but we guarantee that if you follow the instructions step by step in an honest way, without skipping any, you will be able to add the correct logfile every single time.