Hazard vs. Risk
Updated: Feb 4, 2021
In 2007 a study was conducted that concluded children are more inclined to partake risky behavior if they are in a "safe" environment. If there is no real risk children will seek out or create their own danger. To lower risk-seeking behavior the answer was to create play spaces with built-in risk. These places were dubbed 'Adventure Playgrounds'.
Adventure Playgrounds have real challenges children can navigate and explore. Like piles of lumber, hammers, nails, uneven concrete blocks, etc. The most important element in creating these parks is insuring the spaces have risk without "hazard". A hazard is an unknown danger like rotten lumbar that won't bear weight or broken hammers that may fall apart in use. Children can learn how to play safely with risk but they cannot safely interact with a hazard.
I don't mean to compare end-users to children but there is something innate to humans that inspires us to push the limits. Because of this being able to differentiate between a Hazard and a Risk is a critical skill for a tester to mitigate this behavior.
Identifying Hazards in Testing
How do you know if something is a hazard or if it is an acceptable risk? The answer is pretty simple. If it affects user data in an unexpected way, it's probably a hazard. If data can be deleted without the end-user knowing what they're doing, you've got a hazard. If sensitive data is visible in dev tools you've got a hazard. If data can be changed or removed en-mass without warning the end-user, you guessed it, it's a hazard.
As a team it is important to find and remove hazards. Like an adventure playground creator, you want to ensure there are only tools your end-users understand and can use properly. It's not always possible to eliminate a hazard, but it is possible to turn them into acceptable risks.
Turning Hazards into Risks
1. Permissions, permissions, permissions
Does that feature allow deletion of user data? If yes, who can access the feature. What I've heard from our customer care teams is that the less permissions a client has the better. Access can always be re-added but once a client has the power to fiddle with user data it's going to be difficult to remove it.
When working on new features it's important to question "who has permission here" in groomings and product meetings. If the answer is "we haven't thought about it" you may need to put your foot down to get some in place.
2. Back-Ups
How often is your database backed up? Every week? Every night? Is it enough? If there is a place in the system where an end-user can seriously disrupt user data it is critically important that data can be restored. Although the risk of losing data still exists as you'd lose at least a day's worth, backing up the database on a regular basis gives you a fail safe. 'Undo' buttons are also great! Anywhere you have a batch operation is a great time to an 'Undo' option.
3. Slap a label on that sucker
In a system I worked on there was an admin page that end user's had access to. One link controlled user permissions. If the end user clicked one unassuming button they could lock out every. single. user. The best part? There was no warning before or after clicking the button. They would not know anything had gone wrong until the calls started coming in from other users.
This kind of hazard could be completely eliminated by putting some kind of label or pop-up around the feature. If you run into a hazard that you really can't change, this may be the best course of action.
How have you helped to eliminate hazards in the systems you work with? Was there a time when a risk could not be eliminated?
What types of risks qualify as "allowable" to your team?
More Information on Adventure Playgrounds:
https://www.tandfonline.com/doi/abs/10.1080/13575279.2019.1685461?journalCode=cccp20&