Who’s eating my risk?
Testers should have a bunch of really good questions, they’re part of the testers toolbox. They need to know when to use each one and have a variety.
This is one of those, less elegant, questions: “Who’s eating my risk?”. If there’s a risk that renders what you are currently trying to mitigate irrelevant, you’re potentially wasting your time.
Risk is the combination of impact and likelihood. You should be asking the questions: what is more likely to go wrong and what will have a greater impact if it goes wrong. Ideally, a tester should have analysed the risk make-up of a project up front and know the answer to the more serious risks before working on any other risks.
How about an example. You’re pair testing a story with your favorite developer. It’s going great you’ve found all sorts of horrid bugs and fixed them. Once you’ve finished you demo your great new story to the product owner. Done, right? You would be; except none of your users wanted that stories functionality. Worse than that the majority of your users are having serious problems using existing functionality. Worse than that a competitor has announced they are releasing an update which is going to seriously threaten your products value in the market.
Did testing that story really well help? Did it avoid serious risks to your product and company? Nope, not one bit. Could your time have been better spent analysing and reduced those bigger risks? Probably.
That particular risk escalation isn’t unique, there are other routes that it could take. The general idea is to make sure you regularly lift your eyes off the story based work that keeps landing on your desk. Use your skills more broadly in your context. You never know what you may find.
In summary: don’t be the little guy on the right. Nom.