I am unsure how to give feedback to QAs when I think they present problems poorly. E.g. reporting a problem as being extremely specific when it’s actually much larger. Like they will conduct a test and something goes weird and they will report back a new bug as "if you do A, then B, then C, then D happens” without doing any quick checks to see if all those conditions are actually relevant or if actually just doing B is what causes it. Or even that it’s just a global issue that’s affecting everything. Like I don’t expect a twenty page report but any bit of curiosity about identifying what the actual problem is would be nice.
- she/her, sí/í
- oakreef.ie/
꩜ Maker of silly things
Other Cohost pages:
 |  |  |  |
|---|
Other project links:
 |  |  |  |
|---|
How to pronounce my name
ipa-reader.xyz/?text=kwi%CB%90v%CA%B2%C9%99&voice=GwynethMy website
oakreef.ie/Fediverse/Mastodon
cathode.church/@soilseachtTumblr alt
thingswhichdontexist.tumblr.com/You must log in to comment.
in reply to @sundry's post:
yeah, i hear that. it's difficult to communicate why some bug reports are lower quality than others without sounding condescending or nitpicky, but it really does bog me down when the repro contains irrelevant (or even wrong) steps.
at my old gig at a QA outsourcing studio, we were taught to include as much information as possible, and to write as if they'd never used a computer before -- this meant every step 1 was always "Launch the game" or something similar. the granularity of it felt a bit absurd sometimes, but you can kind of understand the logic behind it... text can only provide so much information, after all
in the specific example you mention of potentially useless or irrelevant repro steps -- if you have any evidence or even suspicions or curiosity about a given step not being relevant, including that as an explanation goes a long way. ex: "I don't understand why step B would have an impact on this outcome, because step B is [explanation/not related to outcome]. Is it possible to investigate if this issue still occurs if this step is omitted or changed?" two possible outcomes here -- a) they already tried it without step B and can answer your question right away, or b) they didn't investigate it, but now they have a clear goal to follow up on (try reproducing this issue without step B).
also framing it as "trying to investigate the cause of the issue" vs "trying to investigate why you wrote the bug like this". there's always gonna be QAs who take any bug coming back as some sorta personal slight, and it cant be helped sometimes. but its meant to be collaborative, right? you're trying to help each other get to the bottom of this behavior. its easy to forget that part when you have some kinda quota of bugs to fulfill, when you feel like you're just clocking in at the useless jira factory. but if a bug comes back with a comment written in the spirit of curiosity, well... curiosity can be contagious!
sorry for the long block of text, i hope any of that was helpful at all