Great advice on how to build credibility when raising issues from Vernon Richards (@testerfromleic).
It’s an excellent approach and I think it relies on three things:
How about you, what character traits and approaches have helped you build credibility when you raise a potential issue/bug/problem?
One thing that comes to mind is @therockertester’s article:
Cultivate Your Credibility With Oracles And Heuristics
I enjoyed collaborating with Lee on that one during my days working on a product called TestBuddy.
I usually go for Impact vs Probability
I explain the issue’s impact & Probability and give it a rating from a matrix like so:
I also prefer to explain it in words then just giving it a “medium” label, because that’s when PO’s can really decide what is the issue and how severe is it.
I think that credibility is built over time using a combination of competence, professionalism, and effective communication, much like reputation.
More gems of wisdom from Vernon. It sounds simple when he puts it like that, but so many people take the unwise approach.
I’ve had to earn my credibility on every team I joined. My funniest memory is a developer who just would not engage with me when I tried to explain a serious issue. This is back in the day when we had cubes so tiny, you couldn’t pair at a monitor. And we didn’t have laptops. I finally laboriously printed out all the screenshots of the steps I went through to repro the error, and convinced him to let me show him. With the approach Vernon suggests, “would you please look at this and see if you think it’s a problem?” After I got through something like 15 pages to the error, his face changed and he quickly went to fix the code. He was always willing to collaborate after that.
Nice graphic!
Is this used as a replacement to “Priority/Severity”? Thats the paradigm I came up with. Im wondering if there is a distinction or if its mostly semantic
We might want to distinguish between “Credibility” as a QA resource versus “Good bug reporting”. IMO credibility is built over time - quality of defects filed, subject matter expertise, delivery of metrics, engagement with dev and pm.
Defect reports, for example, have multiple audiences. Are you writing them to appeal to those audiences goals and desires?
Way back in the olden days I was in a seminar taught by Cem Kaner. He posited that our job was “to get bugs fixed” that was a long time ago and some folks may or may not agree with that. The important thing is that it prompted me to do more than just write repro steps and which AC was not met. I began to describe its impact and why it is important with the Product Owner/Manager in mind. So they understood the impact to the user/service/etc. I began time boxing myself to try to root cause, debug or hunt down every bit of information - in order to provide as much information as possible to the developer and thus make it not only important, but easier to fix.
Repeating that effort amongst other repeated activities raises credibility over time.
Thats my take on it, anyways
It’s not a replacement nor the same.
Basically a Priortity/severity is the outcome of this.
When something has a Extreme impact and is Very Likely to appear, then it will get the “Exceptional” priority for us.
Got it! thank you for explaining that