English | EN 
Teams don’t fail because individuals are ignorant. They fail because systems depend on cognitive humility but reward cognitive confidence. We overestimate our understanding, overtrust our own perspective, filter evidence to protect it, believe we control more than we do, and forget that most knowledge lives between us, not inside us.
If risks remain implicit, every quality measure that follows becomes accidental instead of deliberate.
To recap, let’s summarize the discussed cognitive fallacies from the previous blog:
- Illusion of Control → “I believe I can control outcomes that are largely shaped by complexity, chance, or other people.”
- Introspection Illusion → “I understand my own thinking better than others do.”
- Illusion of Explanatory Depth → “I understand how things work better than I actually do.”
- The Knowledge Community → “What feels like my understanding is often knowledge borrowed from the community.”
So, what do we do with this? Within Quality Engineering and Testing, it takes effort to deal with risks explicitly. Risk explicitness is not about slowing teams down, it’s about enabling them to see. Make someone responsible for identifying risks. If a risk comes up, write it down, discuss it, rephrase it, seek shared understanding and agreement. Aim for risk explicitness. Only then will your quality and test strategies be optimal, and waste will be kept to a minimum.
Heuristics for Risk Explicitness
Explicit risk heuristics are good practice. However, these risk sessions only account for a fraction of the time we spend on features. Which means most of the time, conversations around risk take place outside of these sessions.
Risk analysis is a continuous activity. Keep listening for new risks. Make people aware of risks. Apply measures to eliminate or minimize risks. Remember, decisions about risk are for the product owner, or any role responsible for product quality decisions.
The table below lists heuristics teams can use to work towards explicit risk.
| Heuristic | Purpose / Problem it solves |
| Four‑Part Risk Story (Victim – Problem – Vulnerability – Threat) | Turns vague concerns into an explicit, testable risk story. Solves the problem of unclear risk statements like “this might be risky” by forcing cause, impact, and trigger into the open. |
| Risk‑Based Testing | Prevents unfocused testing. Makes risk the explicit driver of test strategy instead of habits, requirements, or test cases. |
| Quality Criteria | Solves functional tunnel vision. Makes non‑functional and quality loss risks explicit instead of assuming “it works” equals “the right quality at the right time”. |
| Heuristic Test Strategy Model (HTSM) | Prevents narrow strategy thinking. Forces explicit consideration of risk across product elements, quality attributes, techniques, oracles, and constraints. |
| Question‑Driven Risk Analysis | Prevents shallow analysis. Uses lists of potential questions for disciplined questioning to surface risks that are implicit, uncomfortable, or not written down. |
| Threat‑Focused Thinking (misuse, abuse, bad input, environment) | Solves happy‑path bias. Explicitly looks for conditions that trigger failure instead of assuming correct usage and stable conditions. |
| Explicit Risk Lists | Solves disappearing risk. Keeps current risk assumptions visible, shareable, and adjustable as learning evolves. Log every risk in natural language into, for example, a table. Discuss risks regularly with stakeholders. |
| Risk Analysis Sessions (e.g. Risk Storming Session) | Solves silent risk. Creates a shared space to surface risks that live only in people’s heads by making risk identification explicit, collaborative, and time‑boxed. |
| Use heuristics | Provides structured ways of thinking when knowledge is incomplete. Helps teams systematically uncover implicit risks and avoid relying on intuition alone. |
Generic quality measures that help address (the cognitive underlying of) implicit risk
Here is a list of quality measures teams can use to prevent cognitive fallacies in the Knowledge Community and address implicit risks.
Make risk and quality explicit
| Measure | Why you use it / what problem it solves |
| Modelling and Visualizing | Transform implicit into explicit representations (e.g. diagrams, flows, models, dependencies, relationships). These expose missing knowledge, hidden assumptions, and unclear system behavior by forcing structure and detail. |
| Dive into expressed risks immediately | Prevents risks from fading away after being mentioned. Preserves valuable risk signals for further analysis and action. |
| Slow down boundary moments (handovers, reviews, release decisions) | Prevents implicit assumptions between disciplines. Forces shared understanding supported by evidence. |
| Confidence votes | Makes uncertainty and disagreement visible instead of hidden behind silence or politeness. |
| Use transcriptions, recordings, and GenAI summaries | Prevents loss or distortion of risk information over time. Enables revisiting what was said. |
| Ask people to explain how a feature works and summarize it | Exposes gaps, misunderstandings, and implicit assumptions by forcing explicit mental models. |
| Pre-mortem | Counters optimism bias. Forces the group to assume the product failed miserably and work backwards to identify what went wrong before it happens. |
| Consider the Opposite | Explicitly asks for reasons the product could fail instead of reinforcing why it will succeed. |
Shift from belief to evidence
| Measure | Why you use it / what problem it solves |
| Specification by Example, Living Documentation, Experimentation and Logs | Shift from “what I think” to “what we observe”. Turns abstract requirements into concrete, testable examples. Reduces (interpretation) risk caused by unknown technical behaviour. Prevents false confidence based on intention rather than actual system response. |
| Focus on interaction with the system | Reveals emergent behaviour and real usage risks that documents don’t show. |
| Systems thinking (focus on the full picture) | Prevents local optimisation. Makes cross‑system and cross‑process risks visible. Such as down- and upstream dependencies. |
| See quality as a property valued by stakeholders, not a role responsibility | Prevents “testers will catch it” thinking and late discovery of quality loss. |
| Recognize a fixed mindset vs. a growth mindset | Makes visible when people stop learning and start defending. Prevents risks being ignored because admitting uncertainty feels like incompetence, and keeps testing focused on learning instead of proving we’re right. |
Deliberately challenge thinking and create psychological safety
| Measure | Why you use it / what problem it solves |
| Take fresh perspectives by using heuristics | Avoid thinking inside the box and repeating familiar but incomplete viewpoints. |
| Recognize fallacies and biases and create awareness about them (E.g. language use, surprise, lack of alternatives) | Prevents teams from mistaking confidence for evidence and ignoring early warning signs. E.g. “This should be easy” or “This won’t go wrong”. |
| Don’t dismiss disagreement as noise or misunderstanding | Treats disagreement as a signal of risk rather than a disturbance. |
| Listen to other experts and understand where insights come from | Prevents authority bias and loss of valuable minority perspectives. |
| Provide explicit opportunities for quieter participants to contribute | Ensuring risks held by less vocal people are not lost. |
| Use safety language (“my best guess”, “where I’m uncertain”, “what am I not seeing?”) | Lowers the threshold to express doubt and surface uncertainty. |
Now you’ve read a bunch of measures and heuristics. Identify a few to investigate. Are they a fit with your context? What problem does your team have? Experiment with the measures. See what sticks.
Which ones are you going to investigate? In which meeting this week will you apply what you’ve learned?
Author disclaimer: During the writing of these three blogs, I was inspired by Rapid Software Testing and the book Taking Testing Seriously (by James Bach & Michael Bolton). Special thanks to Huib Schoots for reviewing.