If you’re a tester or a support person and find a bug in the app you’re testing, what do you do? Ideally, you’d tap the developer on the shoulder, show them the bug, and then they’d fix it. In the real world, you’ll have to log the bug somewhere and then deal with it. So, here are some steps to take when finding and logging a bug.
Identifying the Bug
When you come across a bug, the first thing you should do is try to remember what steps and operations you’ve just done. Take a screenshot and log any console errors if it’s more serious than a typo or dialog out of alignment.
Now, see if you can reproduce the bug. If you can’t, then that’s information you can include when logging the issue. If you can reproduce it, then see if you can do it in as few steps as possible. Do you really need to visit those other three pages before going to the one the problem is on?
With the bug being narrowed down, have you checked the severity of the problem? Does it seem to happen for just one customer or all of them? Just for one type of data or all? If the bug throws an error message, did you stop there? Or, did you okay the error message and check that the app recovered or whether the data was wiped out?
Logging the Bug
Having investigated the issue, it’s time to log it.
First, check to see if the issue has already been logged. Or, see if there is something similar to it that you can add your findings to. That way, you don’t end up logging six variations on the same problem.
When logging the bug, be aware that there will potentially be two different audiences reading the ticket.
One will be the developers who have to fix it, and the other will be management, who will decide if and when the problem should be fixed.
The Developer Audience
They will want to know lots of details, such as:
- The repro steps (obviously)
- How reproducible was the issue? All the time, sometimes, or just once?
- What environment were you on? The live site, a UAT site?
- What browser and OS were you using? It might just be an old Safari version or a Windows problem.
- Any console errors and/or logs to help pinpoint what the system was doing.
The Management Audience
This audience won’t care about the nitty-gritty details, such as the browser version and what steps had to be done. They’ll want to know from the title whether it’s something they care about.
“Page does not load on an iPad Mini in landscape mode” sounds very particular and maybe not something needing urgent attention. However, if you’ve done your deeper dive into the problem and found that it’s actually not working on Safari V14, then “Page does not load on Safari 14” is much more generic. Now management has to decide how far back they want to support.
On the flip side, if you are unsure about how generic a bug is, then be specific. “App does not work on Android” sounds very alarming. “App does not work on Galaxy 7 running Kit Kat” is less likely to set the klaxons going.
Also, ask yourself if it’s something that only a tester would do. (“I cut and pasted War and Peace into every text box while throttling the network and with 140 tabs open.”) Or, have customers also been finding the problem (or are they likely to)?
Is there a workaround for the problem or is the only solution a fix to the program?
All this will help decide when or if the bug should be fixed.