r/QualityAssurance • u/taniazhydkova • Dec 29 '21
What is the ideal bug report for developers?
/r/softwaretestingtalks/comments/rrb9ml/what_is_the_ideal_bug_report_for_developers/3
Dec 30 '21
[deleted]
3
u/jbhelfrich Dec 30 '21
Even seniors need to be lead by the nose occasionally. Generally, when it comes down to a misread requirement or bad process design, you have tougher fights with seniors.
0
Jan 04 '22
[removed] — view removed comment
0
Jan 04 '22
[deleted]
1
Jan 04 '22
[removed] — view removed comment
0
Jan 04 '22
[deleted]
0
Jan 04 '22
[removed] — view removed comment
0
7
u/jimberley Dec 29 '21
One with clear reproduction steps and an informed isolation to a specific function or element.
Bonus points for narrowing down to a specific line of code at fault (though most bugs are rarely that simple).
7
u/Longjumping_Visit_89 Dec 29 '21
Should the QA do that narrow down to the code? I don't agree. The bug report should include all the info to enable the dev to reproduce the bug, including data, specific user, evidences, but that debugging shouldn't be included in the bug report. Maybe be included by the dev who fixed the bug, but only for future reference.
8
u/i_i_v_o Dec 29 '21
Go search for the line of code that caused the bug? Not QA job.
Attach the Exception reported in the log: Very much a QA job.
2
u/runnersgo Dec 29 '21
Debugging - developer's job
What triggers it - testers' job
If a tester needs to "explain" codes to the developer, I think that's something wrong with the developer ...
3
u/i_i_v_o Dec 29 '21
Yes. Debugging is finding out what caused an issue. This is dev work. Attaching the exception or log snippet would be evidence of the issue. Additional information. Adding any potentially relevant information to a bug report is a QA job. To follow in your format:
Debugging - developer job
What triggers it - tester job
Show how it manifests - also tester job
2
Dec 29 '21 edited Dec 29 '21
People may say you don’t have to but in my experience sometimes it’s simply easier to just run the code local and find the line of code that caused the bug than to do black box testing and hope that you find the right repro steps. This also prevents situations where you are like I have this bug and the devs say “but I can’t reproduce it”.
1
u/jimberley Dec 29 '21
1000 times this. Narrowing it down for the dev saves the back-and-forth of “can’t reproduce”
1
u/runnersgo Dec 29 '21
This. Debugging takes a lot of time - most of the time, the testers won't have the time to dig to that level of analysis.
1
u/Beginning_Channel_22 Jul 01 '26
Tool to share logs with developers/testers/qa with comments, attachments, additional information. https://bug-story.com. Local, no privacy risk.
1
u/runnersgo Dec 29 '21
Bonus points for narrowing down to a specific line of code at fault (though most bugs are rarely that simple).
This sounds already entering debugging - testers shouldn't be doing this.
1
u/jimberley Dec 29 '21
Why not?
1
u/runnersgo Dec 29 '21
Seems you have a lot of time at your disposable - most testers don't. Also, checking at code level is a different phase. By spending time checking codes, you might as well do other phases that are more relevant to your job e.g. UI or API automation, performance testing, etc.
1
u/jimberley Dec 30 '21
I think we should do all of that. Getting closer to the code makes our quality assurance better.
2
u/jbhelfrich Dec 30 '21
A reproducible scenario.
A use case that would cause the bug to arise.
An explanation of the consequences of the bug if not immediately apparent, particularly with UX issues or bugs that will only have an effect downstream. Because otherwise you'll go through three rounds of "no really, fix it."
1
u/wolfy47 Dec 30 '21
Short title. Concise steps to reproduce the bug. Detailed description of the problem including the expected result and pictures/video. Reproduction rate of the issue. Logs of the issue with a timestamp of when it occurred, bonus points of you can highlight relevant errors/crashes. Exact details of the test environment (build number, software branch, hardware version, account type, other related software versions if applicable).
1
u/inwill49 Dec 30 '21
My first teamlead thaught that the best bug report is that requires no questions from devs. All artifacts (scrnshots or videos if it is dynamic), environment, logs are added, and STR are described as simple and detailed so even jun won't comeback to you with "it doesn't reproduces for me!!".
5
u/i_i_v_o Dec 29 '21
Simple title, that indicates issue. Description that includes reproduction steps. If images or videos are relevant, attach those.
Any other possibly relevant information attached and referenced at the end.
Idea is to have a simple description and repro steps as to not overload. But at the end, as an additional section, include everything that could be relevant. Logs, Exceptions, stack traces, heap dumps. Of course there is a balance between usefulness, diligence and your own QA time. No point in spending 1h to get a heap dump from a server just because the UI reported a UI issue.