Would you like to know more?
Firstly if you get the reference that the title of this ep is (without googling!), please let me know so I can award you one internet.
Bug reports are an art form. I work with a lot of devs, devs who are good at their jobs and who I have massive amounts of respect for, who I enjoy working with, but, more often than not I’ve no idea what their bug reports are about. Front enders will write bug reports about css elements that are missing, back end devs will write ‘this feature doesn’t work, investigate and fix it’. Which means I have to go and ask what I’m meant to be testing, what the expected functionality should be, where the elements will be applied, things like that. The bug has been put straight in by the dev when they’ve noticed, sometimes before I’ve even had chance to test anything, so I’ve not seen the wrong behaviour, never mind knowing what the right behaviour should be.
So, I want to talk a bit about bug reports, how to write them, how to make them as useful as possible.
So, I find a bug. I double check that I can reproduce it, and I’m not just being an idiot (its more likely than you think!). If it still looks a bug after that I either:
Start writing a bug report if it’s a simple, obvious bug.
Talk to a dev on the project (preferably the dev who did the work I’m testing, but if it’s not obviously related to a feature, the dev I feel will know most about it). The reason I generally try to talk to a dev first is because firstly, dev environments can be a bit weird – features can be switched on or off (sending emails for example, we turn that off on most dev sites and this causes some errors to show), deployments can go weird, things like that. It might be that I just need to clear some caches or similar and the problem will be fixed. Secondly, I might still be being an idiot and not realising, and a second pair of eyes is useful. Lastly, the dev might have some insight into the issue and have some details they want in the bug report. Or they’ll be like ‘Yup, i know what that is, throw it over to me and I’ll fix it’, which if its a bug that’s stopping the story from being passed is a nice way of getting those bugs prioritised.
So, assuming I’ve got to the ‘write a bug report’ step.
Firstly title. I try for short, but sometimes in order to be clear I have to be on the long side. I go for findability over short and pithy. You should be able to figure out roughly what the issue is and what part it affects from the title alone.
Description. More details about user roles it affects, steps to reproduce, expected and actual outcomes. Sometime if the expected behaviour is obvious I won’t put that it, I’ll put ‘we should remove x or something, because sometimes the expected behaviour is obvious and putting it in the ticket sounds really condescending.
Attachments. Screenshots, documents, videos, whatever supporting information I have.
Links. Links to a story or issue if relevant.
Sometimes the bug will be passed to the client or product owner. If it’s a usability issue and we’re unsure how they want the system to work, we’ll pass the bug report over to them and let them feedback on it before any work is carried out.
Decent bug reports are important, and so triaging incoming bugs from product owner becomes an important task. You’ve got to check the bug actually exists and isn’t a user or permissions issue. You’ve got to make sure the description makes sense, and relates to the bug they’re reporting. And then you may need to add to it. Add screenshots, details about reproducing the bug, anything the product owner may have missed. Sometimes this becomes a back and forth with the product owner if the bug report isn’t clear at all. Sometimes you even need to split bug reports up if the report is multiple bugs in one.
Giving devs and testers good bug reports is part of making sure work is carried out efficiently, with minimal re-work/ticket tennis, so I think it’s really important to make sure reports are as detailed and useful as possible.