I made some changes in hopes of making the defect being reported more understandable. We’re using Jira and sometimes I notice that the developer will just paste the same text, as the title of the bug, in the bug description field - since it’s mandatory.
I made a few custom fields and made them mandatory:
I never ever had developers complaining about the bugs I report - they usually tell me that it’s great that I tend to include a lot of technical details, which saves them some time. I did get, on occasion, a snide remark from other testers that I’m being a pretentious smart-ass…
What have you done in the past to improve the quality of bug reporting? Any ideas or suggestions?
Hi @mirza , I think having a structure around the bug report helps especially whenever teams grow and developers have to deal with many different sources of bug report.
Having screenshots or even a video can help, a lot.
Also a clear identification of the version that was tested (e.g., using the Affects Version field); maybe you may need to identify the build number.
Having steps is great but how we phrase things many times isn’t clear and may be misunderstood.
Other fields may be relevant depending on the context of the application.
One field that I’ve used is the “Components” field; some team use this Jira field to identify a certain component of the software… whatever “component” may mean…
I like to be able to look at bug reports and understand what it is impacting, besides the immediate stories/epics. From an analysis pespective, whenever looking at all bugs reported (many may come from users/support team), I want to be able to understand the areas of the application that are being more affected; that may require a separate field, with a set of well-known values.
Another field that I see often is something like Severity… (that field would need to be created) because it is semantically different from the standard Priority field available for Jira issues.
Hope this helps
making fields in any form mandatory creates process friction, in corner cases where someone will just type in “…” as a way to get around it and al you end up with is junk data.
asking a person raising a defect to give priority may be an anti-pattern if you have NOT got a severity field in your system, have a look at using severity not priority. Jira is terrible here, because the person raising an issue has no ability to decide which bugs get fixed first, it’s NOT their job. When raising a bug, all you do know is the severity or the “impact”, you don’t know the actual priority to the business at all, it’s guesswork best handled in a “bug triage” meeting separately.
I prefer free form, because then you can change your process at any time. Also if the “result” and “expected” are really screenshots or bitmaps in paint, they might not fit nicely into your form.
It’s OK to be a smart ass, but process changes are serious experiments.
What I’m missing on your report is the ability to upload a screenshot/gif.
I’ve always recorded a gif, which helps more then just steps to reproduce (feedback from devs)
Other fields, it’s kind of context/project dependent. We like to add “environment” and if it’s “security sensitive” or not.
It’s a bit lower on the list so it’s not visible on the screenahot, but that makes - gif, video or an image means a lot for reproducing issues. I’ll re-arrange the positions to make it more handy, thanks @kristof
@mirza - I really like the format and I do not really get why Atlassian does not make such a setup a standard. Maybe since JIRA can be mega customized they just want to leave that to each Customers preferences.
If I may would add 2 separate fields
Deployed version - since it may be that you get new code to test on your Staging/Test env more than one time a day it would help to know which version ( we use the git hash as indicator) you are testing. It did happen to me that a bug came to retesting but it was not deployed yet ( only took 5 minutes to notice based on the hash)
Browser/Mobile version - Browsers as you know tend to be sometimes special ( thank you Microsoft ). So a feld that shows the Browser with the version that you used for the test would not hurt.
For Mobile thing are I would say kind of straight forward when it comes to IOS but a whole different ball game in the Android world. So also there adding the version that was used to do the test would not hurt.
As for the mandatory and not mandatory that depends a lot on the team that does the work and on the situation, but I can also say that similar to what @conrad.braam said, it can lead to frustration if too much is mandatory and people spend the time adding data to mandatory field x instead of focusing of the application and finding issue.
@mirza - If you ever need JIRA pointer ping me any time. I am a JIRA admin on the side
Thanks a lot @restertest Jira had some surprises for me, I returned the description field since it’s part of a core functionality - hiding it impacted other issue types and disabling it also caused big issues, maybe there is a way around it by making custom screens with all custom fields, but I’m too lazy for that.
The deployed versions and browser/mobile versions are great ideas, I think these fields will come in handy, I got positive feedback from the team about these few changes, so far.
A lot of time is saved when you have relevant logs included, that too insist that the log outputs be in standard formats like JSON. Those type of logs reduce noise, make them machine-readable so that they can be processed automatically. The bug report should include fields for logs which are relevant for the issue at hand.
Also, I see that your image has priority. It should also include severity if it isn’t (I cannot see it from here). They are two different things and have purposes of their own.
Environment (drop-down, set up the test env as the default since most issues are found there)
Severity - set it up to be always visible and placed it to sit next to the Priority field
Browser - since we don’t have a mobile app (just web) set Chrome as default for this one - might add just one more field for the Browser version, may not be as relevant for most issues so I’ll probably set it to hide if it’s empty.
I wanted to thank everyone once more for all the helpful tips, I’ve said it before and I’ll say it again - this community is pure gold!
One more thing which is helpful in JIRA Bug reporting is the ability to relate the bug with any task/user story/Epic and I can not see the relates to option in your screenshot.
Hi @qaisarimtiaz you’re right, that is a really handy feature! I’ve been playing around with linking issues and adding some additional options - I just hope I didn’t get carried away too much
My favorite course in the BBST series was Bug Advocacy. The concepts and methods there could be adapted for any reporting system. I also found course material could be immediately applied to testing work.
My project manager always says “KISS your bug report”. Not literally, but Keep It Super Simple. That if you will show it to your 9yo daughter she will understand what kind of bug you describe. But of course, I think it also depends on what bug tracking system you use (if you do). My assigned developer used to love Trello for this purpose but he would always get frustrated if he can’t find a ticket there. So we switched to aqua ALM instead. They don’t have a specific templates but the dashboards organized in the way you cant miss a thing to put in your bug report. And also you also can tag a developer or send him notification right from the created item, which made my life less stressful. Plus customized fields also helped a lot
). So a feld that shows the Browser with the version that you used for the test would not hurt.
