The audience for this is just the immediate dev team (manager, Scrum Master, PO, developers).
I totally agree with the KISS approach - I’m really trying to keep this SUPER simple (otherwise no one will give a crap nor use it). I’m the only QA person in-house - I’m happy to educate but I do want this to be easily understood by non-QA.
My goal is this: have an at a glance way for others on the dev team (it’s a rather LARGE team) to see a high-level view of the current “assessed” product quality. I have one item I’m struggling with putting into words, maybe you can help me figure that out…
Question to be answered with this chart: If we were to release today, how are we feeling about what we KNOW on the product quality?
Here’s where I’m at so far - I’ve pared it down from 6 columns to 4 and it looks like so (excuse the cruddy table, I’m not sure how to format it here!)…
Product | Testing Type | Quality Assessment | Comments
Product A | Functional | | Passed Testing
Product A | Non-Functional | | Ticket #355 - Cancel button missing on new screen
What I don’t like about this is Testing Type because it’s not widely understood. I almost broke it down by testing type but that’s a TON of granularity for a team that just wants the big picture. What I’d like to include instead is Area Tested or something to indicate different testing requirements that have to be met. For example… I could have one for Functionality (includes system, integration, end to end, stress testing, etc) and one for UI (which includes the design requirements, usability, etc). But I’m struggling with the wording… I looked at Bug classification for a bit but can’t quite put my finger on what I’m looking for.