Reporting bugs, it is important not only to have the correct and accurate description but also to specify what exactly was tested and on which platform the testing was performed. These nuances are specified differently by each company. In this article we’re going through the QATestLAb company’s requirements for reporting bugs found on the mobile devices.
«Must-haves» for mobile bug reports
Bug report attribute requirements
Environment
Mobile testing implies several options:
- Testing on real devices (best option);
- Testing on the emulator;
- Testing using the developer tools in the browser.
Let’s look at the example of the environmental description in the «Mantis» bug-tracker while testing on real devices. There are «Platform», «OS» and «OS Version» fields in this system for environment description. In our case, in the «Platform» field we should write the word «Mobile», the «OS» field should specify the name of the mobile platform (Android, iOS), and the «OS Version» field should contain the version of the operating system.
When testing on the emulator, the «Platform» field should show the name of the emulator, the «OS» and «OS Version» fields should specify the platform that is being emulated and its version.
Sometimes, for the quick layout testing or when the necessary device isn’t available and the emulator can’t be installed, the browser developer tools can be used. Of course, this method is highly inaccurate, but it can approximately show how the site will be displayed on the device. In this case the «Platform» field should contain the name and version of the browser installed on the PC, and the «OS» and «OS Version» should contain the name of the used operating system and its version, respectively. Also, it should be specified in the section with additional information that testing was conducted with the Developer tools, as well as what device was chosen and its screen resolution.
Summary
In our company, it is required to specify the word [Mobile] and OS where the testing was conducted in the beginning of the summary, so the developer could realize and note to themselves that the bug was found on a mobile device just by looking at the bug-report summary.
For example: [Mobile] Android: The keyboard is displayed in the portrait orientation on the registration form after tapping the name field and switching the device in the landscape mode.
Also, it is required to specify in the «When?» part what is the phone mode (portrait or landscape) if the bug appearance depends on the orientation switching.
Steps to reproduce
Testing sites, this section is described the same ways as for the desktop. First step should contain the link to the main domain, and then list what should be opened and what should be clicked. It is important to use the right terminology while describing touch screen gestures, especially you should pay attention to it when reporting the bug in English. More detailed information about the gestures names can be found in the article.
The download link is not necessary in the first step when we are testing the app. It is enough to specify the name of the app in the «Additional information» field.
Additional information
This field is filled in often and with a lot of information when testing on mobile. Testing the site on the mobile device the browser name, its version, the name and model of the device should be specified in this field. However, while testing the app,its name should be specified instead of the browser.
Attached Files
Also, don’t forget about the screenshots and video that demonstrate the bug. The screenshots should contain the red arrow and rectangle that highlight the found defect. The methods of taking the screenshots on mobile devices are described in detail in the 6th lecture of the «Software Testing: Basics and Practice» course.
At the first glance, the rules described above can seem weird and inconvenient, but in reality they’re making life easier for the developers who will read the bug-report. Most products nowadays are multi-platform, so it is important to understand immediately on what version of the product – the mobile or the desktop one – the bug was found.
