Leading on from last week’s show, I want to talk about prioritising and risk assessment. I’ve spoken a little bit before about how I use AC as a base for my testing – that’s the highest priority, then I spread out from there.
I think there’s some merit to timeboxing things off and focusing your time for a tight time period, like 15mins of focused testing and see where you get. This I think is true for security updates that might have an effect on various parts of the site as well (talking from a Drupal point of view, we recently had an update that may have affected some custom work we’d done, so I gave that custom work a test through). As an aside, the ten minute rule for test plans1I think is useful, and I have definitely found that AC take less time to write and review once I’m in that focused mindset, and it cuts the fluff that doesn’t need writing, that can be left to the test sessions.
But how do you prioritise what you test after AC? How do you prioritise bugs when you report them (and defining blocking bugs as opposed to ones that need fixing, but don’t block the story from passing, if you even differentiate them. I try to keep blocking bugs to bugs that I wouldn’t want the work going live with, but that doesn’t always mean the AC isn’t being met. So sometimes that requires a discussion of ‘is this a blocking bug, or a bug we’ll tackle as part of the bug fixing part of the sprint? Should we log it but throw it to the client to prioritise?) Which comes down to:
• Risk of fixing it vs. Risk of keeping it as it is
• Complexity of the bug and fix
• The timings of the project
For example, we work with Drupal, one bug we came across recently had a fix that involved upgrading a module to the dev version. This was the version after the latest stable version of the module, and so there was some risk attached to it; it wasn’t used widely, hadn’t been crowd tested like the stable version had. The site we had the bug on is a large site with lots of users. The bug was relatively small, and had a workaround. We decided to spend some time investigating alternatives, but if we couldn’t easily find an alternative fix within the time we had, we could offer a workaround, and wait until the dev version of the module became the stable release. It just wasn’t worth the risk of upgrading to a potentially unstable module version that could have unknown effects over a large site, that we didn’t have teh time to fully investigate, given we could offer a decent workaround to the client.
On the flip side, a client asked us to spend some time and effort looking into a complex change request – changing how out of hte box functionality worked and looked for them. For us it didn’t seem like a high priority, and was not complex, but not easy, but the client prioritised it, so we did the work, anf the client was happy. We also was able to contribute this back to the community, for other people to use if they found it useful.
Which I guess highlights that there will sometimes be conflicting priorities from a developer and client point of view, and sometimes concessions and compromises have to be made. This does depend on the client, as there will always be some who will think everything is top priority all the time, but sometimes a discussion is needed.
I think conversation is one of the most important things when it comes to prioritising and risk assessment, and I do think I’m getting better at spotting which bug I need to get developer input on before marking it as blocking or not.
And sometimes the conversation ends up like my second anecdote back there, where we ended up contributing to a larger community, and that’s always a good thing.
As an aside, I want to throw a podcast recommendation at you. All through recording this episode, I’ve had the soundtrack to a podcast called Risk!2 In my head. Its the opposite of everything this podcast is. The tagline is: True Tales, Boldly Told, and its “where people tell true stories they never thought they’d dare to share in public”. Its often NSFW or children, but its also funny, or touching, or any other number of things. Its well worth a listen, if you enjoy listening to stories.