This is one of two heuristic approaches to risk analysis and evaluation that considers different types of quality threats. The other is Loss vs Harm. These two types of approaches to risk can be combined together into one quadrant.
Not Doing What It Should vs Doing What It Shouldn’t
When testing, it’s easy to focus only on the things that software is expected to do under a given circumstance and investigate when it’s not doing so. However the opposite is also true, it’s also important to look out for when the software is doing something that wasn’t expected under a given circumstance. This creates two broad categories of risk that testers consider when testing otherwise potentially important bugs may be missed:
- Doing nothing at a time when it was expected to do something
- Doing something at a time it was expected to do nothing
This may be in the same area that the tester is looking at but is a problem or output they’re just not attuned to, or in a completely different area of the software that may not be visible. Taking a step back, thinking what else may be affected by the test and monitoring logs are all good ways to avoid this bias and hypothesising risk in testing. It’s also beneficial to keep in mind different bias, quality dimensions and consistency principles in mind to give the tester the best chance of noticing different types of problems when they occur.
Example
A self-driving taxi delivers value to passengers by having them pick them up from a specified pick-up point, drive them to their destination and then drop them off at their target.
A passenger is able to change their destination mid-route and have the driverless taxi drive them to their new destination. However there was a problem where the taxi didn’t take this new instruction and instead drove to the original destination before the passenger had to start a new journey. Something was expected to happen in this situation but was no change from the current behaviour.
On the other hand, a passenger was viewing and adding new favourite destinations to their driverless taxi phone app. Apart from adding the destination, nothing else was expected to happen but a bug in the phone app meant that any new favourited destination made while in an active journey became the new active journey’s destination with the taxi immediately rerouting the passenger there.. Nothing was expected to happen in this situation but something unintentional did and there was an additional change in behaviour.