Category Archives: Testing

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

Rethinking Testability

Posted on by
Reply


Before summer, I had the chance to share my new talk:
Improving Quality of Life Through Testability at GreaTest Quality Convention
It’s a topic that still doesn’t get enough attention — which is why I’m bringing it here, in a 4-part blog series.
Over the years, I’ve collected lessons, stories, and patterns from my own work and from teams I’ve worked with. My goal is to show a different way of thinking about testability — one that’s built for people, not just systems.
When most people hear “testability,” they think about code.
But in my 25 years in software, I’ve learned it’s about much more than that.
Poor testability shows up as slow feedback, missed bugs, fragile automation, and even burnout.
And it’s everywhere — sometimes in ways we don’t notice, because we’ve accepted them as “just how things are.”

Here’s what’s coming up in the series:
1️⃣ Testability Is About People, Not Just Code
→ A more human-centric definition and why it matters.
2️⃣ Poor Testability Is Everywhere — But We Don’t Always See It
→ The recurring patterns and the invisible friction that holds teams back.
3️⃣ The Triangle of Perception
→ Why different roles see the same system’s testability in completely different ways.
4️⃣ Changing the Conversation About Testability
→ How reframing gets people to listen — and the risks that come with 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.

Are you really a Test Coach?

Posted on by
5

For many years we have seen different kinds of coaches appearing within software development. As more and more companies strive to become agile, various types of roles are becoming obsolete or transformed into something different. The most prominent one seems to be Agile Coach. In the software testing domain it is the Test Coach or the Quality Coach.

The transformation and changes in expectations of a role have in my experience caused some identity crisis within the testing profession. Even though there is a need for testing many companies choose to remove the tester as a role. (This post is however not about testers so I will not continue down that road).

As for myself I’ve been struggling to put a label on the work that I do. For those who know me I am not a big fan of titles and labels, although they can be helpful in some contexts. My work for the last few years have focused on transformation and how testing needs to be interlaced with development. Many of the companies I’ve worked with do not even have testers.

Coaching

Last year I went through a nine day training to become an ICF Coach. During that course I had many great insights. One of them relates to the Coach in the context of Software Development. A few times I’ve labeled myself Test Coach or Quality Coach but I struggled a bit with those titles as well. I just felt they didn’t really do justice to my work. In the context of coaching a coach is an expert on the process of coaching and is someone who facilitates learning.

“A coach is an expert on the process of coaching and is someone who facilitates learning. “

The client is the expert but the coach helps the client to unlock their potential to maximize their own performance. A skilled coach knows that the individual has the answer to their own problems.

A coaching approach

Why I struggled with titles like Test Coach became very obvious during my coach training. I was presented with the following model, “The flower”, created by Polhage & Lundberg, who also run the training (the model is originally described in Swedish and this one has been visually modified by me). They differentiate between the coach as a profession and having a coaching approach. We can always apply a coaching approach whether it’s in our daily life or at work.

The flower petals represents several roles which we might step into during our daily life or at work. The Coach is one of these roles (and the one I was in training for).
You can move between these roles and decide who to be in different situations. As an example, sometimes you need to take decisions based on your responsibilities which makes you the Decision maker. The empty petal is left for you to decide what to put in there. Your flower might have many more petals.

No matter what profession or role you have you can always apply a coaching approach. This means how you act and relate to the values of coaching.

The root system represents eight characteristics to consider for constructive communication, which are used in a coaching approach.

I quickly realized why I have never been very fond of the title Test Coach. It doesn’t fully reflect what I do or who I am. I am a subject matter expert in testing trying to help an organization, a team or an individual to improve their testing by guiding them and showing what to do, how they can do it and why.

“I am a subject matter expert in testing trying to help an organization, a team or an individual to improve their testing by guiding them and showing what to do, how they can do it and why.”

But I am also a Decision Maker, a Teacher, an Inspirer and a Mentor (for those who choose me to mentor them). I shift a lot in between all of these. One role I have never used at work is the Coach. However I often apply a coaching approach. This is an approach where I ask questions, where I use my curiosity to understand where the team or individual is right now and where I display my courage to challenge and ask “uncomfortable” questions. Focusing on what works and what moves us forward is also part of what I apply in my daily job whether my title is Project Manager, Test Coach or Scrum Master.

The only time I have been the Coach and only a coach is when I am a professional Coach in an agreement with a client.

Coaching in software testing

I recently had a short assignment where I was asked to coach a tester. She needed someone to talk to regarding her own journey where she was leading a change in her organization. In the beginning I found myself struggling with who to be. Biased by my recent experiences as a Professional Coach I started off in that role but quickly understood that my client needed something different. The focus was more related to guidance around the change she was implementing at work rather than her own journey. Sometimes it was hard to separate her own growth from the approach to testing that she was implementing.

Something that is very important is the agreement that you come up with before starting the sessions. The purpose of that agreement is to build trust and set expectations. Though this situation was a bit new for both myself and my client we decided to keep an open dialogue along the way to make sure she got value from our sessions.

My learning experience here is that it is not as black and white. What title you carry is not as important as the approach you choose.

“What title you carry is not as important as the approach you choose.”

During these sessions I used a coaching approach – actively listening, asking questions, driving my client to find her own solutions based on where she and her team are right now. In the cases where she wanted me to share my experience and thoughts, I did that as well.

What are your thoughts regarding coaches in Software Development/Testing?

References

Polhage & Lundberg

International Coaching Federation

Boosting your creative thinking

Posted on by
2

PART 1 – of a short series around creative thinking and testing.

Yesterday I facilitated a workshop on creativity at a local conference Testit in Malmö. The purpose was to share some ideas of how to boost your creative thinking and some tools of how you can improve your thinking around test ideas.

Our testing is only as good as our thinking and many times we are held back by deadlines, limited time, poor communication, knowledge and pre-defined roles and responsibilities.

I have a certain process which I go through when ever I create a workshop or an exercise. Usually I start with an idea and a purpose of what I want the participants to learn. I trust my process of where I will come up with exercises which fits the purpose. This is the part which I get the most excited about, where I let my creativity flow. I play with different ideas, tools and media. I might experiment and try my ideas on colleagues and friends. I want my workshops to be interactive, fun and experiential where my work is much more about facilitating learning and creating opportunities than traditional teaching. I want my workshops to be fun. The most difficult is to balance the fun and the learning. What I mean is even though I aim for fun and play, that can’t take away the focus on the learning.

Like many times before I trusted my own process about putting my workshop together in time for the conference. I wasn’t worried, I had some ideas pondering but nothing really tangible. I knew I would come up with something. Surprisingly that didn’t happen. I realized I kept procrastinating my preparation and the day for the conference just kept coming closer and closer. I could not even force myself into designing my workshop.

My creativity was gone! What happened?!

To be continued…

Part 2 – Where did my creativity go?