How a Tester can make a Developer’s life easier
A few tips on how you can reduce comes and goes with developers
Working in a remote environment means communication is going to be a challenge, therefore the more organized a development process is, and how everyone understands this process is crucial to achieve a good outcome.
As an iOS developer i have come across different projects with different testing teams and strategies. In the past, i used to work with QA teams on site so if i had any question about a certain bug, the tester was just a few seats away.
Nowadays i work remotely and things get a little more complicated, so today i want to focus on a few things testers can do so that we (developers) spend more time solving bugs, and they (testers) spend less time explaining.
Follow a bug template
If Developers and testers agree on a format to report a bug, and they follow it every time, then there is less chances that some information related to the bug may be missed.
For example:
Platform: iOS
OS: iOS 13.4 (all OS used to test)
Device: iPhone X ( all devices used to test)
Environment: SITTitle: Offers list not refreshing on pull to refresh actionDescription: When accessing the home screen and trying to refresh the offers list by swiping down the list, the loading indicator stays on loading indefinitely Prerequisites:
User is already logged in.
Credentials: testUser@test.com pwd: Test@123Steps to reproduce:
* Load App by tapping on dashboard app's icon
* check that splash screen appears
* check that splash screen disappears and Home screen is loaded
* check that offers are loaded in the list
* pull down to trigger refresh actionCurrent behavior: Loader indicator is stuck spinning indefinitelyExpected behavior: Loader should spin until offers are refreshed and displayedMedia: (Screenshots or video of the bug)
The template above provides a detailed guide that a developer can easily read and follow to reproduce a bug. He has all the information he needs: the how: (steps to reproduce) the where:( device, OS and environment), the who: (pre requisites) and also media to support all the above.
Omitting some information can lead to the developer not being able to reproduce the bug, which leads to having to ask for more info to the tester who will then reply after some time and it could end up in a pretty long loop with lose of time and it can also build frustration.
Test in real devices
Avoid using Simulators to test. Simulators are great for development, but they will never be as reliable as testing in a real device.
While testing, do it in real devices with settings and configurations that common users will have in their devices when using the app
i have come across testers that report bugs saying:
“it works fine in my personal device but it doesn’t work in testing devices”
What are developers supposed to do with that information?
Having tested a feature in multiple devices is much much better than doing it in a single device. If a bug is found in one device but not in another one, then you can specify the device type in your bug template, this will help the developer greatly. If a bug is found in all devices, then the bug is not device specific and the developer will know better how to attack it.
Avoid the word “Intermittently”
When reporting a bug, like we mentioned before you want to be as specific as possible on how to reproduce it. If you write something like
“The app crashes intermittently”
Or
“The account information takes too long to load”
This is not clear and specific information, it is relative to the tester. What is too long?
- 30 seconds?
- 2 min?
What does intermittently mean?
- happens 1 out of 10 times?
- happens 4 out of 10 times?
- 9 out of 10?
When you don’t know exactly how to reproduce a bug 100% of the times, try to give as much context information as possible so that the developers can reduce their focus to fewer potential causes. Provide videos, screenshots, all tested devices information, and any thing you may think could be useful for the developer to try to figure out the issue
1 bug report for 1 bug
When writing a bug report, make sure the report is related to just the bug you are reporting, mixing bugs in a single report, ticket, etc, will cause confusion and it will make it harder to understand.
A good way to know if what you are reporting is ok, is by being able to describe the bug in 1 line, even maybe in the title. If it takes a paragraph to describe the bug, then probably it can be divided in several bugs
for example:
“when pulling to refresh offers, the loader keeps spinning forever and also if a push notifications was visible, when we tap on it, the app is redirected to the User profile screen instead of redirecting to the user’s transactions screen”
Most likely the offers refresh functionality has nothing to do with the notifications issue, so mixing both issues will make the bug harder to reproduce and even harder to solve since the developers will be trying to solve two unrelated bugs at the same time.
Also it will probably happen that one of the bugs gets resolved but the other one does not, and then the bug ticket report needs to be updated with just the remaining bug.
So try to report small bugs, with clear titles and few steps to reproduce.
Inform the status of a bug
If you are using some tracking system like Jira, tickets or issues will be changing state all the time. If developers are assigned to a ticket or following its state, they will get noticed of their updates, but it is a great idea to tag a developer in a bug report and leave a comment with the status of the bug after being re tested, or even send them a private chat message with the corresponding status information.
“bug #3453 is still reproducible with the same steps as before”
or
“bug #3453 is solved”
It could also happen that by solving a reported bug, another feature got broke, and we have a new bug. Even if the new bug is related to the old done, DO NOT KEEP WORKING ON THE SAME BUG. Solve or close the current bug, and report a new one. Otherwise you’ll end up having to update the description, steps, media, and again this is a potential way to confusion, errors in the report and misunderstandings with the developers.
Hope this tips are useful, and soon i will be writing on things a Developer can do to make a Tester’s life easier
