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 it is not the seemingly logical one.
House is right (of course) and the patient is cured. And we are explained the reason of 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 fix the bug.
But who is our House? Who is the mystical figure who will discover the reason of 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: 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:
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.
To avoid longer steps, it is better to use “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 “Update Profile” screen under “Settings” menu.
– Turn off Wi-Fi connection.
Steps to Reproduce (Actions Performed):
Make sure that your reproduction steps are clear, easy to read, in order, preferably numbered do not fail. Do not forget that a lack of clarity may lead to misunderstanding that can assigned back to the reporter as “Request more information.” which slows down the resolution process.
Tap on “Upload Image” button, user is redirected to “Camera Roll” screen.
2. Select an image, user is redirected to “Update Profile” screen.
3. Make some changes on “First Name” and “Last Name” fields.
4. Tap on “Next”.
5. Observe that “You don’t seem to be connected to the internet.” warning message doesn’t appear.
All too often, we see customers reporting bugs which 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.
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 it 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 an 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.
http://www.mobven.com/wp-content/uploads/2017/08/test.png423738Emre Balkanlhttp://www.mobven.com/wp-content/uploads/2016/06/logo.pngEmre Balkanl2017-08-14 18:07:532017-10-19 10:09:19What is Test Automation? Manual Testing vs. Automated Tests
http://www.mobven.com/wp-content/uploads/2017/05/po2.jpg423738http://www.mobven.com/wp-content/uploads/2016/06/logo.png2017-05-11 14:35:152017-05-11 14:48:18Congratulations on your new role, now you are a "Product Owner"