Why trying to fix a ‘poorly reported bug’ reminds me of House M.D. (yes, the TV show)?
For those who are not familiar with the popular TV show House MD, generally, the plot goes like this:
- A patient showing bizarre symptoms is admitted and we quickly understand that if the cause of the symptoms can’t be discovered fast enough, the patient is going to die painfully.
- Theories from underdogs fly around and are checked one by one, generally under a lot of stress because the patient doesn’t have the time for all theories to be tested.
- House has a different approach, he looks where nobody looks, thinks what nobody thinks, and prioritizes one theory above all others even if it is not the seemingly logical one.
- House is right (of course) and the patient is cured. And we have explained the reason for House’s decision which is a small, sometimes environmental detail missed by everyone but him.
I have used this analogy because fixing bugs, especially in UAT, is a lot like a House episode. You have bugs (symptoms) that are reported that you have to fix, a customer breathing down your neck with a deadline (painful death), and multiple theories to fixing the bug.
But who is our House? Who is the mystical figure who will discover the reason for the bug and apply the necessary treatment?
Well, truth to be told, we don’t have a house and since we don’t live in a TV drama series, we don’t believe there could be one such all-knowing figure. Instead, a pretty rigorous discipline that we impose both on ourselves and customers: is the discipline to report a bug in a well-documented way so that we have all the facts before starting the investigation.
What is “well reported”? For any developer to produce a reliable theory for the cause of a bug, he/she first has to reproduce it, and to do that, he/she will need a number of elements which include internal and environmental information:
Build Version:
It is very critical for the developers to know on which build the bug was encountered. It may seem trivial, but you would be amazed to know the number of times the developer and the reporter are not working on the same build.
Preconditions:
To avoid longer steps, it is better to use the “Preconditions” section effectively. You don’t need to go over and over again the steps that you’ve been through. Developers don’t like when the report looks unreadable. So, instead of listing out every single step to reach where the main issue lies, start your steps with “Preconditions” as mentioned below as an example:
– Login to your account.
– Navigate to the “Update Profile” screen under the “Settings” menu.
– Turn off the Wi-Fi connection.
Steps to Reproduce (Actions Performed):
Make sure that your reproduction steps are clear, easy to read, in order, and preferably numbered do not fail. Do not forget that a lack of clarity may lead to a misunderstanding that can be assigned back to the reporter as “Request more information.” which slows down the resolution process.
Example:
- Tap on the “Upload Image” button, the user is redirected to the “Camera Roll” screen.
2. Select an image, and the user is redirected to the “Update Profile” screen.
3. Make some changes to the “First Name” and “Last Name” fields.
4. Tap on “Next”.
5. Observe that the “You don’t seem to be connected to the internet.” warning message doesn’t appear.
Environment:
All too often, we see customers reporting bugs that are caused by connectivity issues; without checking that fact, your dev team can search for ages without being able to reproduce the bug and frustrate the customer in the process. Other environmental factors like OS version and phone model may turn out to be critical as well.
Example:
Tested with: iPhone 6S — iOS 9.0
Tested on: External Release — 1.0.0.90
Connection: Wifi / LTE/ 3G
Memory: %43
Attachments: Screenshots, Videos, Error Log Files
Attaching screenshots shows the context of the related issue quickly and helps to complement written details. Also, in case of a crash, you can pull the error logs and attach them to your report.
Not as easy as “the complete order button doesn’t work when I want to finish my order” right? Taking all the screenshots, annotating & comparing them, and adding all the environment details with logs is no easy task but has to be done to avoid spending the time that you don’t have when your patient is dying.
We thought that if we couldn’t have House in the real world, we could have the next best thing: a tool that lays all the details and factors bare for the developer to see a developed Capture. Capture is a simple and easy-to-use bug reporting tool, which does all the legwork for the reporter and leaves him only the bug description. It takes screenshots, lets the reporter annotate them & add a description, and when he is finished, gathers all the environmental details and logs and opens a Jira task automatically.
Capture was developed for internal purposes but we decided to bundle it as a product when we saw how useful it turned out to be for every organization developing mobile apps.
We can’t guarantee to heal your patients but we can guarantee that you will have all the information you need right before your eyes to do so.
