How to Write A Good Or Bad Bug Report?

[Ronan Healy]

Following on from the still popular conversation on rejected bug reports, and seeing as so many are discussing bug reports being rejected, I thought it would be good to discuss what a good or bad report looks like?

Obviously there are certain criteria and details that you should include for a good report? E.G. Good description, title.

Were you taught what to include/what not to include?

I also thought about how to approach a good bug report from the opposite side. I’m sure there are plenty of bad bug reports that everyone has encountered? There must be some examples out there like the “system is very slow ” or “clicked button, stopped working.”

[stefan]

I rarely have seen the mistakes you talk about on testers tickets. Testers usually try to enter multiple details even if sometimes some of them get left out.
But developers, product managers/owners, marketing, support are really bad at writing bug tickets in general. Examples are as you’ve mentioned:
“Client can’t see his latest updates on the platform, probably a caching problem again.
Please fix it”
I have also lately noticed that tickets with longer descriptions and steps are not read completely. What is over 4-5 lines gets ignored by almost everyone, maybe except some developers.

I’d suggest when creating bug tickets picking of words carefully, being concise, maybe split the bug description in two parts – intro(a bit more info than the summary of the bug) and detailed version with steps included.

As for being taught, not so much but practice helped a lot. The Bug Advocacy course from AST just supported my way of thinking: http://www.testingeducation.org/BBST/bugadvocacy/

[Joe]

I have also come across the bad tickets. Similar to Stefan it tends to be Developers with one liners that do not make a lot of since.

How I would tend to write a ticket is the steps carried out (numbered), the expected results and the actual results. And where possible screenshots. Also it can be quite long but the title of the ticket should usually have a fairly detailed e.g ‘Log on button on search tab is not working’.

[Gita]

This is what I wrote as guideline for good bug report to my company and it has been really valuable to send it to clients as well. It’s always a bit hard for people who have never written bug report to write one, so help them out! 🙂

Good bug report should contain:

• Summary – short explanation
• Description – long explanation
• Minimum steps to reproduce (be specific what you did before to get to error)
• Actual / Expected results – what you think should have happened and didn’t
• Browser, Link, OS, Version, Device
• Screenshot or error message
• Proofread

Problems with bad bug reports leads to time consuming activity to clarify them and kicking them back / forward from one person to another.

Common mistakes in reporting bugs:

• Too vague or unclear description
• Unclear where issue was found
• Two bugs reported in one
• Duplicate of existing issue
• Too technical to test
• Too personal

[Ronan Healy]

@Gita That’s a great summary. Did you compile the list based on experience?

From what you are saying @ipstefan testers need to be careful with their description in a bug report. Is it possible to be concise and descriptive at the same time?

[Ron]

I would like to add a few items to Gita’s awesome good bug report list. If the bug was found while executing a specific script, include the following

Case/Scenario name
Step number
Iteration
If appropriate – who you were logged in as (user, admin, ……)

Once resolved, having the resolution included within the completed bug report would probably be a good thing.

[Jon]

There are few “soft”items to consider:

1. enough info to have the issue be repeatable
2. be written to not make the developers “unhappy” (don’t call the developers baby software ugly)
3. provide enough history and information to support after the fact big data analytics

For these, it may be good to get full team “buy in” on the report itself. This can happen at a change board or review meeting.

[Gita]

@Ronan Yes, list was basically done based on experience. I actually did brown bag about it taking examples from our bug tracking system. So while some bugs might found funny to read, they are rather hard to test.

@ronp really good points. Lately I have been lots of ad hoc testing which quite often isn’t that official, but I have worked in companies before, when details you noted should be added to bug reports. Definitely worth it if you have well written test scripts!

@jonhagar I completely agree that issue reports should have enough info to repeat, but quite often I see random bugs that are really hard to reproduce. So I raise low priority bugs and note that I saw them once. Then if I see them again, I add more and more details to the bug till it’s reasonable to give to developer. If it never happens again, they get closed after a while on some sprint planning. My point is – never loose bugs even if they appear only once, because there might be possibility that some clients will get that as well.

On impersonal point – I would quite often re-read my bug reports and make them less personal. Sometimes I don’t even write ‘I clicked on button and then I noticed there was an error’ but instead ‘Clicking on button, there is an error on website’ – so nothing says who did it.

[Paul]

I don’t think anyone has mentioned the importance (often, but perhaps not always) of indicating the things which do not cause the defect to manifest. That is the isolating information to help the PO understand it better and the Devs to work productively on it.

For example does it only affect joint applicants or solos as well? There’s no point in recording that you can’t open an account, suggesting that 100% will fail when it’s actually only joint applicants who are porting a mortgage over £400000 and who work in the recording industry – that’s rather less than 100% of use cases. It matters

[Author]

Posts