Category Archives: Software testing

From Templates to Heuristics: Enhancing Thought Work

Posted on by
2

Update 2025-10-14: This post has been updated to reflect thought work rather than knowledge work – which was pointed out by Fiona Charles as a much better description of the cognitive work performed in software development and testing. I fully agree with the distinction between knowledge work and thought work where knowledge work rather describes what LLMs do:
“..it works only from stored knowledge, matches patterns, makes some clever (we hope) predictions and does not think.” – LinkedIn post by Fiona Charles

Anime-style illustration of five software professionals sitting around a conference table, all facing a large screen displaying a colorful risk matrix grid. Each person is working on a laptop and focused on the discussion, suggesting a team analyzing project risks or testing priorities.
Risk matrix template

I once worked with a team that used a risk-scoring template.
Each risk got a number for probability and another for severity, and they multiplied them to get a total. It was meant to help decide what to test first. But as I listened to the team debate whether something was a three or a five, I realised the discussion wasn’t really about risk at all. No one talked about what those risks meant, how they might unfold, what could be done to reduce them, or what we still needed to learn.

Maybe that happened because the template did not even include “impact” as a separate topic. But I suspect the deeper issue was competence. A team comfortable discussing risk would have gone there instinctively. Here, the numbers took over and the thinking stopped.

That moment has stayed with me because it reminds me of something I’ve experienced many times. something subtle about thought work:
The way a tool is meant to guide thinking can instead replace it.

When the Form Becomes the Focus

Templates, checklists, and frameworks promise structure and consistency. In software development and testing, they’re everywhere. Test plan templates are one of those I encounter every now and then. They usually have sections for Objectives, Scope, Risks, Environment, and Schedule. It looks thorough and reassuring. It appears like you can fill one out without thinking too hard, and that’s the danger.

When a template becomes the focus, attention shifts from outcomes to outputs.
The document starts to stand in for the thought that created it. We stop asking, “What problem are we trying to solve?” and start focusing on, “Have I filled in all the sections?”

In that shift, responsibility quietly moves from the person to the process. The template gives a comforting illusion that the work has been done, even if the real thinking never happened. For people with less experience, it creates false confidence: “anyone” can fill in the blanks, so the work starts to look mechanical rather than cognitive.

A test plan template, for example, gives the impression that testing can be planned like construction: linear, predictable, and tidy. But testing is exploratory by nature. It’s a way of learning about a product, not just confirming what we already know. A static plan can’t capture that. It diminishes learning to a document.

In my experience, test plans and test planning often look different depending on the maturity of the team. In a mature team, the outcome of a planning session might be mind maps, whiteboard sketches, or lightweight notes. They are living things, short, imperfect, and full of questions. The content still matters, but the conversation around it matters more.

When Templates Actually Help

Of course, not every task in software development demands deep reflection.
Some kinds of documentation are about communication or traceability rather than discovery: release notes, version information, configuration details. In those cases, templates can be genuinely helpful. They save time, bring consistency, and reduce the chance of missing something important.

There’s nothing wrong with that. Not all work is thought work, and not all documentation should invite debate.
The key is recognising which kind of work we’re doing. If the task is largely mechanical, a template can be a useful shortcut. If the task depends on judgment, understanding, and interpretation, then a template can easily get in the way.

The problem isn’t that we use templates; it’s that we often use them everywhere, without stopping to ask whether the work in front of us is about recording information or making sense of it.

The Catch-22 of Structure

The irony is that templates usually appear with good intentions. I know this because I have created lots of checklists myself, and at first glance they might even look like templates. They promise consistency, a shared language, a way to make the invisible parts of thought work visible. And they can help. When a team is new to a problem, a bit of structure can keep things from drifting. But what starts as a way to get moving can easily turn into something that boxes people in.

To use a flexible template well, you already need the maturity that makes rigid templates unnecessary. Without that maturity, the structure that should support learning ends up replacing it. Too much structure, and people stop thinking; too little, and they struggle.

There is another layer to it as well. When a process takes over, it gives people somewhere to hide. If something goes wrong, we can point to the document and say, “But we followed the plan.” That is the quiet harm of too much structure: it makes accountability procedural instead of personal.

What breaks that loop, in my experience, is not another process but leadership, coaching, mentoring, and showing a different way of working. When people feel what it is like to work that way, to discuss, to question, to reason rather than just fill in forms, they discover that outcomes can be achieved without a template. That experience changes something deep.

I once coached a team where we decided to stop using the formal test plan template. We did not replace it with anything fancy. We just started each conversation with one question: “What do we need to learn about this product?” We used heuristics to guide our thinking. It was messy at first, but soon people began to ask sharper questions and share more ideas. The documentation did not disappear — it just looked different, smaller, and better.

From Templates to Heuristics

In thought work, I have found that heuristics serve us better than templates.
They might look similar, a list of things to consider, but the mindset is different.

A checklist says, “Do not forget these things.”
A heuristic says, “Think about these things, if they matter in this context.”

Heuristics make that kind of thinking visible.
When I test, I sometimes use heuristics like “How might this fail?” or “What happens if/when…?” They are not rules; they are reminders. Each one starts a conversation with the product rather than trying to control it.

Over the years I have collected and written about several testing heuristics and mnemonics such as SFDIPOT, RCRCRC, and FEW HICCUPS. Each serves as a prompt to think, not a promise of coverage. For readers who want to explore them more deeply, I have shared examples and links in a separate post.

What makes heuristics powerful is also what makes them fragile. They help us navigate uncertainty, but they can easily harden into rules. Checklists assume the situation is stable; heuristics assume it is not. Checklists aim for control; heuristics invite judgment.

I find heuristics fragile for another reason too. The moment I write them down, they risk becoming the very checklists they were meant to replace. Heuristics are rules of thumb meant to guide problem solving, but they are not guaranteed to be optimal or perfect. In my experience, your background, exposure to similar situations, and worldview all influence how you apply them. That makes heuristics both contextual and fallible.

The trick is to share them as conversation starters, not commandments. When I share a heuristic with someone, I try to say, “This is something that helps me think; see if and how it helps you.” That small disclaimer keeps the door open for learning.

That is also why I have grown wary of “best practices.” To me, they are just templates at scale: frozen examples of what worked once, somewhere. Good practices live in context. They grow out of the people, the product, and the problems at hand. They shift as those things shift.

Culture, Competence, and Confidence

The difference between a template that helps and one that harms often comes down to culture. In a reflective culture, a template is often a prompt for conversation. In a compliance culture, it is more like a box to tick.

I have seen both. In mature teams, templates are used lightly, edited, reworded, sometimes ignored when they do not fit. In less mature teams, templates are treated almost as sacred text. The organisation starts to value uniformity over understanding.

The paradox is that, in my experience, competence and culture grow through practice/doing, not through documents. That is why demonstration and coaching matter so much. You cannot change this with policy; you nurture it by showing what good thinking looks like.

Over time, that creates its own kind of structure, a shared sense of what good work feels like. When a team reaches that point, even if they reintroduce some form of documentation, it is no longer a threat. It becomes expressive rather than prescriptive; it records thinking instead of dictating it.

Competence Before Templates

Competence is what allows people to see context, to tell when a template applies, when it does not, and how it might need to change. Without competence, every good practice turns into a rule, every heuristic into a checklist, every conversation into a template.

So maybe the real principle is simple:
Structure seems to work best when it grows out of understanding and experience, not the other way around.

When we reach for structure before understanding, we trade thinking for form. But when we build understanding first, structure becomes a natural by-product, a way to capture and share what we have learned, not a way to avoid learning in the first place.

Maybe that is what maturity really means: not the absence of structure, but the ability to use it lightly.

The longer I work in this field, the more I’ve come to see that thinking is the real craft. The tools change, the processes come and go, but the ability to pause, to ask why, to connect dots — that’s what lasts.

I’ve realised I don’t reach for templates because they don’t fit how I think.
They make me feel limited, because thought-work isn’t linear.
Thinking, for me, has never been about ticking boxes. It’s about staying close to what’s real — even when it’s messy, uncertain, or hard to explain.

So now I’m curious:
When do templates and checklists help you think better, and when do they get in the way?

Learning Faster: Deadlifts, Software Testing and Feedback Loops

Posted on by
Reply

Reflections emerged from learning to deadlift

Many years ago, I decided I wanted to get really good at deadlifting. I can’t quite remember why, but at some point I thought: women who lift heavy are pretty badass. And I wanted to be badass too.

At first, I thought the deadlift would be simple. You just pick up a barbell from the floor, right? But like many things that look simple on the outside, the deeper I went, the more complex it became. Hip hinge, grip, bracing, bar path, leverages — all of it mattered. And because I tend to get nerdy when I learn something, I didn’t just practice in the gym. I was simultaneously watching endless of tutorials, reading articles and forum threads, and even rehearsing the hip hinge and the feeling of a proper lift without a barbell. Yes you would find me pretending to deadlift everywhere – at work, at home, in the grocery shop.

The more I dug in, the more I realized how much my progress depended on the feedback I was getting. Sometimes it came instantly, sometimes much later — but the faster and more diverse the feedback, the quicker I learned. I was starting to see some parallels connected to my profession – it reminded me of the feedback loops in software development and testing.

Reflection 1: Not All Feedback Is Useful

One of the first “feedback tools” I tried in the gym was the mirror. It gave me an instant reflection of my movement, which sounded useful in theory. In practice, though, it wasn’t reliable at all. To check myself, I had to turn my head or shift my focus — and that immediately changed my form. The feedback was there, but the very act of observing interfered with the movement.

Software has its own “mirrors”. Sometimes we interact with a system and it looks fine — the page loads, the button clicks, the response comes back — but that doesn’t mean it’s really working the way we expect.

Feedback through mirror

The feedback can be shallow, or even misleading. Other times we add log statements or quick checks that give us a sense of what’s happening, but only from a narrow angle. Just like the mirror in the gym, these signals can create an illusion of confidence while hiding what’s really going on. The real value comes when we go deeper and investigate beyond what’s immediately visible.

Reflection 2: Fast Feedback Accelerates Learning — Especially with Multiple Inputs

Feedback from recording

Recording myself in training sessions became a turning point, even if it felt really awkward at first. With video, I could almost immediately see what had happened and adjust in the very next set. That kind of instant loop accelerated my learning curve enormously.

But the video wasn’t the only input. Sometimes I could feel something was off — maybe my balance shifted, or the bar drifted away from me. That sensation alone didn’t always tell me why it happened, but the video often did. And the best feedback of all? A coach standing right beside me, shouting cues in the middle of the lift — “brace more!” or “push the floor away!” That was immediate, specific, and actionable

Testing is similar. We learn fastest when feedback is both fast and comes from multiple angles:

  • The system itself giving you signals (logs, responses, performance “feel”).
  • Tools that capture and replay what happened (recordings, traces, automated checks).
  • A colleague or peer review pointing out what you might have missed.
  • Pairing with a colleague to give a richer perspective of ideas and feedback on your own thoughts.
  • …

One perspective rarely tells the full story. It’s the mix of inputs that accelerates learning.

Reflection 3: Interpretation Unlocks the Value of Fast Feedback

Here’s an interesting note: when I first started lifting, I wouldn’t have known exactly what to look for in a video. A rounded back or hips rising too fast didn’t mean anything to me until I had learned what good looked like. Fast feedback was only useful once I had the knowledge to interpret it.

It was similar to when my testing team was asked to explore the product for security risks. They were skilled testers, but security testing was not our area of deep expertise. We could follow guidelines, try common attack patterns, and note down the responses we got — but we didn’t know whether what we were seeing was truly a vulnerability or just expected system behavior. Even when we followed recommendations from checklists, we were left wondering: Is this a real threat, or just noise?

What we really needed was someone who could interpret the signals with expertise — a security specialist who could look at the same output and say, “Yes, this is dangerous,” or “No, this is fine.” Without that, the fast feedback we were generating didn’t translate into learning. This reminded me of the feedback I got from the coach, an expert on deadlifting. So once I had learned what to look for I could make sense of my videos.

Speed matters enormously — but it only accelerates learning if you can make sense of what’s coming back.

Reflection 4: We Can Shape the Loops

As a lifter, I learned to adjust my loops. Filming myself gave me near-instant replays. Writing a training journal and reviewing previous recordings helped me see trends across months. Without those adjustments, my progress would probably have been slower.

Sometimes, I even shaped the lift itself to get more feedback. Slowing down the movement — adding pauses at the knees, or deliberately descending very slowly — gave me more time to feel what was happening and notice where my position was breaking down. It wasn’t about moving more weight, but about creating a training scenario where I could learn more from each rep.

In software, we also have the power to shape our feedback loops. We can choose what to observe, how to surface information, and how quickly we get it. Sometimes that means speeding things up — shortening build times or adding logging — but sometimes it means slowing down on purpose. Taking time to explore step by step, to add more observability, or to walk through a workflow carefully can reveal details we’d miss at full speed.

The goal isn’t just to get feedback faster — it’s to design feedback that accelerates learning.

Closing Reflection

Software testing, like lifting, are practices that can look easy from the outside. To someone watching, it may seem like a tester is just “randomly pressing buttons.” But underneath, there’s intention: forming hypotheses, observing carefully, connecting signals, and adjusting based on feedback. Sometimes that means repeating a scenario to learn more, sometimes it means trying a completely new approach.

Of course, there are huge limits to the analogy. Deadlifting is more of a physical skill where I train my body to move well and stay strong. Testing is a cognitive skill where I train my brain to form , notice patterns, challenge assumptions, and explore risk. But the small parallels circles around the need for feedback: both require listening carefully — to your body or to the system — and using that information to adjust.

When feedback is fast, you accelerate not only your progress but also your ability to adapt. Whether it’s correcting a mistake, fine-tuning a movement, or exploring a new path, quick feedback shortens the time between action and adjustment. It gives me the ability to spot patterns faster.

And that’s the real carry-over. Under the barbell or inside a product, progress comes from designing and using feedback loops that are fast enough to guide the next step, diverse enough to reveal different perspectives, and deep enough to provide value.

Deadlifting and software testing look completely different on the surface, but at their core they are both ongoing practices of learning — ways to continuously explore, learn, adjust, and improve.

On a side note I actually don’t do conventional deadlifts any longer.

Changing the Conversation About Testability

Posted on by
Reply

Rethinking Testability Part 4 (Last post) – A series of blog posts based on my talk Improving Quality of Work and Life Through Testability


Rethinking Testability Part 1 – Testability is about people, not just code,  Part 2 – Poor Testability is Everywhere – but we don’t always see it Part 3 – The triangle of Perception

Reframing Testability

Over the years I’ve learned that: Starting a conversation by talking about testability, I can lose people pretty fast.

Not because they don’t care about it — but my guess is that testability just sounds too niche, too tester-centric. And to some it might just seem too technical and maybe a bit too dry for people to immediately feel connected with.

So I started framing it differently.

Leading With Developer Experience

Instead of testability, I’d talk about Developer Experience — or sometimes Developer Productivity, depending on who was in the room.

I genuinely care about Developer Experience — and it overlaps heavily with testability. And it seemed like that concept is easier for people to connect with.

Most developers know the pain of:

  • Waiting forever for a build to finish.
  • Having to restart flaky environments multiple times a day.
  • Wrestling with tools that block instead of help.
  • Getting interrupted mid-flow by issues that shouldn’t be issues.

Those things drain energy, slow learning, and make people feel less effective.
When I talk about them as Developer Experience problems, people nod immediately.

But here’s the thing: those are also testability problems. Because every one of those frictions makes it harder to observe, control, and explore the system.

Where Productivity Comes In

On the other side, Developer Productivity is a term that seemed to often land better with leaders or managers, because it speaks directly to business outcomes: speed, efficiency, predictability.

If you say “poor testability slows us down,” you’re talking productivity.
If you say “better testability means faster learning and fewer surprises,” you’re also talking productivity — just in a way that connects risk and speed.

The overlap is there. Testability affects both how productive teams feel (experience) and how productive they are (output).

But here’s the risk: if I only frame it in terms of speed, I risk losing the deeper point. Testability isn’t about going faster —it’s about efficiency, how easily we can explore a system, uncover risks, and challenge the product itself.

The Catch-22 of Testability

One of my biggest challenges is that: improving testability often feels like a Catch-22.

  • To show the value of improving it, you first need better conditions.
  • But to get those better conditions, you often need to show the value up front.

I’ve seen this happen with tools, environments, and processes. Everyone would benefit if they were more stable or better supported. But getting buy-in often comes down to one question – related to productivity:

“How much time will this save?”

It’s a fair question. But the real value isn’t only about saving time.
It’s about reducing blind spots.
It’s about enabling exploration earlier.
It’s about noticing problems sooner — and avoiding the burnout of constantly fighting the system.

Those benefits are harder to measure, but they’re the ones that really matter.

The Bigger Picture

This is the thread running through the whole Rethinking Testability series:

  • Testability isn’t just about code.
  • Poor testability shows up everywhere, often in invisible ways.
  • People perceive it differently depending on how they interact with the system.
  • And the way we frame it shapes whether others understand its value.

At the heart of all of this is one simple idea: testability shapes quality of life.
Not just the quality of the product — but the quality of life for the people building it.

Improving and Advocating for Testability

Improving testability isn’t the responsibility of one person or one team — it’s something we can all influence:

🔍 As a tester
Don’t just share results — share the story behind them. If it was painful to get there, that friction is a signal. Speaking up about it reveals risks others can’t see.

💻 As a developer
Think beyond “code that works.” Ask yourself: can someone easily observe, control, and explore this system? Design for exploration, not just validation.

📈 As a leader or product owner
Seek real confidence, not just green dashboards. Ask: where are teams fighting the system instead of learning from it? Your support can make the difference between friction and flow.

The Takeaway

Testability isn’t really about speed. It’s about making our work smoother, our learning faster, and our confidence real. And when we improve it, we’re not just improving our products — we’re improving the experience of everyone building them.

That’s why I believe testability deserves more attention.
Because quality of life at work isn’t separate from quality of the product. They rise and fall together.

Rethinking Testability Part 1 – Testability is about people, not just code,  Part 2 – Poor Testability is Everywhere – but we don’t always see it, Part 3 The Triangle of Perception: Why we see testability differently

The Triangle of Perception: Why We See The Need for Testability Differently

Posted on by
2

Rethinking Testability Part 3 – A series of blog posts based on my talk Improving Quality of Work and Life Through Testability


Rethinking Testability Part 1 – Testability is about people, not just code,  Part 2 – Poor Testability is Everywhere – but we don’t always see it

Japanese anime styled picture. A triangle in the center of the picture. To the left a girl with brown long hair faced towards the triangle and in dialogue with black haired guy to the right of the triangle.
Triangle of Perception

Same same but different

Two people can work on the exact same system and what seems to be the same problem— and yet live in completely different worlds.

I learned this many years ago—I was working with a developer, asking to improve the logs to help us catch subtle problems. But we saw logs very differently: for me, they were essential; for him, they were occasional – which made him question the investment and the time needed to improve the logs.

As a tester, logs were really important to me. I relied on them not just when something was obviously broken. I needed that observability before anything failed. It helped me spot anything weird—things that might not be visible through the UI.

For the developer, logs were something he dug into after a failure—part of troubleshooting a known issue. Logs were helpful, but only needed now and then.

We weren’t disagreeing on whether logs were useful.
But how often we needed logs and how we used them, what we used them for – shaped how we saw the need for investing in better testability.

Three Factors Shaping The Perception of The Need For Testability

An animated picture in black and white with a triangle in the middle. To the left you can see the shadow of a person with short hair. On the right the shadow of a person with long hair. They both face the triangle. On top of the triangle is a text- view of testing - inside the triangle is a text - Perception of tstability. In the left corner of the triangle it says - usage of the system. In the tight corner of the triangle it says - frequency of interaction
Perception of Need for Testability Triangle

Over time, I started noticing a certain pattern.
It seems like different people’s perceptions of the need for testability are shaped by three main factors:

  1. Frequency of interaction — How often do you work with the product? Daily? Occasionally? Rarely?
  2. Usage of the system — How do you interact with the product? No matter if you are building it, testing it, observing it — When you do work with it, are you going deep into the system or just skimming the surface?
  3. View of testing — Do you see testing mainly as confirming known behaviors, or as exploring the unknown?

When your answers to those questions differ, your sense of what’s “good enough” for testability will differ too.

Confirmation vs. Exploration

An animated picture in black and white with a triangle in the middle. To the left you can see the shadow of a person with short hair. On the right the shadow of a person with long hair. They both face the triangle. On top of the triangle is a text- view of testing - inside the triangle is a text - Perception of tstability. In the left corner of the triangle it says - usage of the system. In the tight corner of the triangle it says - frequency of interaction
Perception of need for Testability

I’ve noticed that the third factor — how you see testing — is the one that changes the conversation the most. Note – I am clearly polarizing and exaggerating the views, to make the distinction more clear.

When someone sees testing as confirming expected outcomes, they’ll judge testability by how easily they can check the known. In my experience it seems like the symptom of this is a huge focus on testability for automation.

But if we see testing as exploration—about learning, discovering, and questioning—then what we need from testability will be different.  We need to support serendipitous exploration—being able to notice something interesting and then quickly dig deeper without friction.

Unfortunately, most organizations I’ve worked with lean heavily toward optimizing for confirmation and verification, maybe because it’s easier to measure. Exploration often gets left behind and when that happens we risk missing the bugs that really matter. For more on this topic see my post on Testing Beyond Requirements.

Why This Matters

When someone nods along as you talk about improving testability, it’s worth checking:
Are they picturing the same thing you are?
Or are they imagining something completely different?

That shallow agreement can be dangerous — because it hides the fact that you might be solving for entirely different problems.

Rethinking Testability Part 1 – Testability is about people, not just code,  Part 2 – Poor Testability is Everywhere – but we don’t always see it

Poor Testability Is Everywhere — But We Don’t Always See It

Posted on by
4

Rethinking Testability Part 2 – A series of blog posts based on my talk Improving Quality of Work and Life Through Testability

Part 1 – Testability is about people, not just code

Poor testability Slows everything down Adds risk Increase cost Delays Poor quality
Poor Testability

Symptoms of Poor Testability

I’ve worked with a lot of different teams and organizations over the years, and I’ve seen the same problems repeat themselves in places you’d think had nothing in common.

Sometimes the symptoms are obvious but very often not understood as testability problems.
– A test environment that is not available.
– Logs which are unavailable or hard to read.
– A new team who is not yet familiar with the product.

The Patterns I Keep Seeing

When testability is poor, I usually see some mix of these five problems:

  1. Late discovery of critical bugs — the issue was there, but poor observability or unstable environments kept it hidden until too late.
  2. Intermittent issues that slip through — the right conditions to trigger them are too hard to create on demand.
  3. False confidence — the green checks hides how much effort it took to get there.
  4. Missed learning opportunities — we stop exploring and only do the bare minimum to getthrough.
  5. Burnout — constant friction turns the work into a grind.
Comic strip with a distressed man in front of a computer screen and text saying I once worked at a place where a memory leak took down the website in production. We’d seen symptoms of the issue during testing—but because our environment was flaky, we had a habit of restarting the server. The warning signs were there. But because of distraction from poor testability, the bug stayed hidden until it was too late.

The first four mainly hurt the product – at least at first.
The last one hurts people.

The Burnout Nobody Talks About

One of the hardest moments I’ve witnessed came from the fifth problem.

A tester I worked with broke down in tears. Not because of bad feedback from a manager, or a bug escaping to production — but because every single day was a fight just to do the basics.

He couldn’t get the system into the right state.
He couldn’t trust the tools.
He felt blocked at every turn.

That’s not “just part of the job.” That’s the personal cost of low testability – and a loss for the organization where this person works.

The Invisible Friction

Sometimes poor testability hides in plain sight — we’ve just gotten used to it.

On one project, a tester had to go through the entire customer journey before they could even start the actual test:
Simulate a purchase — > Step through the install flow — > Confirm the configuration
Every day. Several times a day.
Nobody questioned it. It was just the way things worked.

Until one day, a developer sat down, watched the whole process unfold, and said:

“Wait… you do this every time? I have a script that does all of that.”

That moment said it all.
Sometimes the biggest testability problems aren’t hidden in the system — they’re hidden in our habits.

How to Spot It

The power of pairing

If your team is struggling with testability — whether you realize it or not — there are a few ways to surface the pain:

  • Pair up — have someone from another role watch you set up and run a test. Fresh eyes see friction you’ve stopped noticing.
  • Map the setup — document the steps just to get into a testable state. Investigate which of those could be simplified or perhaps automated/scripted
  • Ask “how” and “why” more often — tell the story of how it was tested and why, the story about the testing itself may reveal interesting information about testability.
  • Run a testability workshop with your team — these are workshops that I often run with teams and it starts with a simple question: “What is making it hard for you to test?”

The Real Point

Poor testability isn’t always loud.
Sometimes it creeps in slowly, hidden behind workarounds and “just the way we do things.”

But whether it’s obvious or invisible, it is costing us.
It costs us time, it costs us learning, and — over the long run — it costs us the energy and motivation we need to do our best work.

Rethinking Testability Part 3 The Triangle of Perception – why we see testability differently

Testability Is About People, Not Just Code

Posted on by
4

Rethinking Testability Part 1

Poor Testability

I’ve lost count of the times I’ve seen similar scenarios play out:
A tester — or sometimes a developer — spends hours just getting the system into a testable state. By the time everything is finally configured, they’ve got maybe twenty minutes left to actually do the testing.

They don’t complain.
Nobody on the team does.
It’s just how things are.

But to me, that’s not just a scheduling hiccup or a minor annoyance.
It’s a symptom of something deeper: poor testability.

The Narrow View That Holds Us Back

In my experience, when “testability” comes up in technical discussions, it’s almost always framed in narrow, code-focused terms.

The ISO 25010 standard, for example, defines it as:

“The degree of effectiveness and efficiency with which test criteria can be established for a system, and tests performed to determine if they’re met.”

It’s not completely wrong — but it’s incomplete.
This definition treats testability as something the system has, as if the only point of testing is to check that known expectations are met.

But testing is so much more than that. It’s about learning. It’s about discovering things you didn’t expect. It’s about questioning assumptions and exploring risks before they turn into real problems.

When we define testability too narrowly, we risk building systems that are easy to check but hard to learn from. And that’s where the real damage happens!

A More Human-Centric Definition

Dimensions of Testability

After 25 years in software development, here’s how I see it:

Testability is how easy it is for a specific person to test a specific product in a specific context.

That single sentence changes the conversation.
It forces us to look beyond the code and think about:

  • Who is doing the testing, and what skills and knowledge they bring.
  • What tools they have, and how easy those tools are to use.
  • The culture of the team, the pressures of deadlines, and the development practices in play.
  • The architecture and purpose of the product itself.
  • …the list continues. For a deep dive into the dimensions that affect Testability – have a look at my previous work on testability.

These aspects aren’t fixed. They shift over time — even within the same team. What feels smooth and straightforward to one person might feel painfully slow to another.

That’s why I don’t think testability is about speed. It’s about effort — how much effort it takes for this person, in this moment, to make real progress in testing.

Why This Matters More Than You Think

When testability is low, it doesn’t just slow down releases or make bug-hunting harder.
It drains energy. It discourages curiosity. It not only undermines confidence in the product but may also create a dangerous illusion of reliability.

In my experience, many people look at a green test suite and assume everything’s fine. But they don’t talk about what it took to get there.

Tests passed—but only after multiple retries.
Or the environment was unstable, so corners were cut.
Or the system was too painful to set up properly, so we didn’t test very deeply.

That struggle—that story—rarely show up in the report.
It’s all green.
It’s an illusion based on data with no context.

I’ve seen skilled testers spend most of their day wrestling with flaky environments instead of exploring the product.
I’ve seen teams skip entire categories of tests — not because they didn’t care, but because the setup was too painful.
I’ve even seen burnout happen not from impossible deadlines, but from the constant grind of fighting the system just to do the basics.

The hardest part is that burnout doesn’t stay at the office. It follows people home. It affects evenings, weekends, families, and mental health.

Poor testability might look like a technical issue on the surface, but its impact runs much deeper.

So – Improving testability isn’t just a technical win. It’s a human one.
It changes how smoothly we work, how quickly we learn, and how confident we feel about the results we’re getting.

Where to Start

If you want to improve testability in your team, start by looking beyond the code.

  • Talk about people, not just systems.
     Ask: Who’s testing this, and what do they need to succeed?
  • Look beyond speed.
    Faster isn’t always better. Less friction is better.
  • Measure the effort, not just the output.
    Track how long it takes to get into a testable state, how easy it is to observe and control the system — not just how many tests pass.

Testability is a reflection of how we work.
When we improve it, we’re not just improving the code — we’re improving the whole experience of building and testing.

Rethinking Testability Part 2 – Poor Testability is Everywhere – but we don’t always see it

Heuristics applied when opening a safe lock

Posted on by
1

When teaching testing I often talk about heuristics. Everyone uses heuristics whether you are aware of them or not. Simply explaining heuristics – A heuristic is a rule of thumb. It’s an approach or a method of how to a solve a problem. It’s important to remember that all heuristics are fallible.

In software development we use heuristics everyday. Your heuristics are build upon your experience. This is why I find it extra interesting comparing my heuristics with those of my children, who have different experiences than I have.

A few years ago when my kids still played with toys, I was in the bathroom getting myself ready for the day when I heard my youngest daughter crying from the other side of the wall. I opened the door and asked her what was going on.

“I can’t open the safe lock and I have all my money in there. We have forgotten the code and now we can’t open it.” Of course I went to see how I could help them.

My oldest daughter was sitting on the floor and furiously shaking the safe. She mumbled something about how she had changed the code a while ago. They had tried several different codes but with out any luck. So I sat down on the floor with my daughters and asked them to show me what happened when they entered the code.

They entered a code. “Error” was shown on the display and the safe made a kind of buzzing sound indicating that something was wrong .

I asked them what different things they had  tried to do to open it. They had actually tried several things like

  • Trying to remove the hinges. Kind of clever I think ( but it might have broken the toy).
  • Searching the internet for how to open the safe.
  • Tried different codes.

Suddenly my youngest shouted, with pride in her voice: “We can use a saw and cut it open!” We chose to proceed without bringing out the saw since they really liked their safe lock.

Opening the safe box

20210510_164603

To give you and idea of how the safe is opened, I have provided a short gif and a brief explanation. There are actual sounds made for each action you do but since I can’t upload videos without upgrading my account to Premium this will have to do. You just have to imagine any toy with sounds and I bet you will understand how this quickly can drive you crazy…

  1. First insert a plastic “key” card (sound played).
  2. Press the button “Withdraw” twice. Not sure why it needs to be pressed twice (sound played).
  3. Then enter your code (sound!). Another sound is played when the code is correct. You can then open the safe with the black handle below the “Withdraw” button.

Heuristics applied

Before moving on with some ideas that came into my mind we tried a few codes again but without any luck.

Since the safe box actually had some software I used the “Long press heuristic” hoping I could reset the software. I even tried combining different buttons hoping to trigger some error which would reset the safe. Yes, this has actually happened before!

I then went with the “Google search heuristic”. It had already been tried by my children but I had a deeper knowledge of how to search the internet. This unfortunately didn’t help either and to be frank I was more eager to interact with the safe lock rather than reading.

When this didn’t help, I wanted to use my “Remove the batteries heuristic”. It was a long shot but it was a toy so maybe removing the batteries would reset the code. While doing so I discovered a tiny hole next to where the batteries goes.20210507_184255

You might wonder why I didn’t look for it when considering to reset the safe code – but it just didn’t cross my mind. As a side note there is a cognitive bias called the Hindsight bias, which is very common and also known as the “I knew it all along” phenomenon. The effect of this bias is that it causes us to overestimate our ability to predict events. And might also be a reason for you thinking – “I would have looked for the reset option the first thing I did.” Maybe you would have – maybe you wouldn’t. 

With excitement in my voice I asked the children to go get me a tooth pick. Again I was using my heuristics – “The press reset with a tooth pick heuristic“. I pushed the tooth pick into the tiny hole. The safe made a new type sound and seemed to be reset. “Wohoo! Could this be it?”

We inserted the plastic card, pressed the withdraw button twice and then pressed the code several times without any luck. The fourth time the safe made a new sound ( described as a sad sound by the children), a light went red and then the display was blank. This was a different behavior! Intriguing!

I noticed that the text on the display was very hard to read. It was not very bright. My youngest used her little hand to shadow the display to make it easier for me to read. I suspected that the batteries might be running low so we changed the batteries. And voilà we could finally open the safe.

My heuristics were build upon my experiences with toys, software, and software and hardware working together. Experiences which my children did not yet have. Some were consciously applied but I am certain there were several unconsciously used heuristics as well. Also by interacting with the toy, exploring different alternatives serendipity might have played a part here too. I still don’t know why the safe wasn’t reset properly after pressing the reset “button”. In hindsight it could have been waiting for a new code to be entered but that hypothesis have yet to be tried.

A toy safe is however different from a real safe. The context of where the heuristic is applied is of great significance.

To read more about heuristics in Software Development and Testing the following article, Software Testing Heuristics: Mind The Gap! by Richard Bradshaw and Sarah Deery is a great starting point containing a long list of references.

Mnemonics and Heuristics

Posted on by
3
“A heuristic, is any approach to problem solving, learning, or discovery that employs a practical method not guaranteed to be optimal or perfect, but sufficient for the immediate goals.” Wikipedia

“A mnemonic device is a mind memory and/or learning aid. Mnemonics rely on associations between easy-to-remember constructs which can be related back to the data that is to be remembered.” Wikipedia.

Remember that all heuristics are fallible.

These are the mnemonics and heuristics I use the most:

RCRCRC

Regression Testing Heuristics by Karen N. Johnson
Recent, Core, Risk, Configuration, Repaired, Chronic

SFDIPOT (San Francisco Depot)

Test Strategy Heuristics by James Bach and Michael Bolton
Structure, Function, Data, Integrations, Platform, Operations, Time

CRUSSPIC STMPL Quality Characteristics Heuristics by James Bach

Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility, Supportability, Testability, Maintainability, Portability, Localizability

A variation to these heuristics can be found here. I like the added Charisma-heuristic http://thetesteye.com/blog/2010/11/software-quality-characteristics-1-0/

FEW HICCUPS

Test Oracles by Michael Bolton

Familiarity, Explainability, World,  History, Image, Comparable Product, Claims, User Expectations, Product, Purpose, Standards and Statutes,

RIMGEA

Bug Advocacy Mnemonic by Cem Kaner

Replicate it, Isolate it, Maximize it, Generalize it, Externalize it, And Say it Clearly and Dispassionately

MOCHA

For asking questions in e.g an interview – by Maria Kedemo

Meta, Open, Closed, Hypothetical, Audit

 

 

Here are some more which you might find useful