In Chapter 18 of “Taking Testing Seriously” (I skipped ahead, sue me), Keith Klain says:

So much today is about “continuous everything” - continuous deployment, continuous integration - and speed. The pace at which people are doing things is really, really disruptive to thinking deeply about problems. Then the goal gets displaced from getting good products and services to customers quickly, and turns into, “How do we back something out quickly when we inevitably screw up?” It’s continuous everything - except continuous thinking.
- Taking Testing Seriously, James Bach, Michael Bolton et al., 2025, p. 424

He has a point. But I got there by first kind of disagreeing with what he said. Because “continuous everything” is not about speed. It’s about risk. Or rather, about managing certain risks: the risk of (code) integration and the risks of delivery/deployment. And how fast you go, should not just be determined by those two specific risks. (Or even worse, by the fact that you just think it’s really cool that you can release every commit to your users.) It should be determined by your overall risk appetite, which is a much broader perspective.

Read more…

Testing types in software testing are a mess. It’s not just “regression testing” that can mean more things than there are people in the room. It’s true for basically all of them.

Just last week a teammate said “We should also do integration testing.” So I asked “What do you mean by integration testing?”. And the reply was: “Testing the frontend and backend together using Playwright.” Which made me think “I see what you mean, but I would never call that integration testing.” and made me reply: “Yeah, we should.”

The typical solution to this problem is to start defining the different testing types. To me, that’s just one approach of many to make sense of testing types. So far I’ve come up with an additional five.

Read more…

At the first conference I ever attended - or I think it was the first, in any case it was Let’s Test in 2012 -, I asked someone “So what kind of applications do you test?” And the reply was: “One of the onboard computers of a Saab fighter plane.” While at that time I was the test lead for an enterprise service bus.

We do not all have the same job.

In a recent episode of the Quality Remarks podcast hosted by Keith Klain, Paul Holland told the story of an organization where running the test automation took 13 people two weeks. And no, I’m sorry, they didn’t go into any detail about what happened in those two weeks. In my current project our pipeline takes 0 people about 17 minutes to run.

We do not all have the same job.

Read more…

In a previous post I claimed that any set of principles (or methodology for that matter) for good software development should cover these five areas:

• collaboration
• software engineering
• work management
• product
• reflect & experiment

I mentioned these five again in my post “What is a scrum master?”, but that’s all I’ve said about them. That changes with this post. I will provide a brief description for each of the five areas. I’ll share some ideas how a list of the five areas of Agile might be useful. And I’ll reflect on the question: Are they the five areas of good software development or of Agile software development?

Read more…

How does a project get to be a year late?
…One day at a time.
- The Mythical Man-Month (anniversary edition), Frederick P. Brooks Jr., p. 153

Last week I found a minor bug in the application my team is building. For every election committee, we have a page showing all sessions of that committee. These sessions are shown as a row of cards. Playing around with the number of sessions, I discovered that the row keeps on growing, resulting in a horizontal scroll bar:

Read more…

I wish people would share more of what they do day-to-day. Especially testers and quality engineers. Show the work you do. On the other hand, I do realize that that’s hard. You don’t want to share sensitive information. You want to respect the privacy of your team. And then there’s the whole practical side. How much of the context do you need to share to have an intelligible story?

Since my current project is open source and my team works in public, I have more options than most. So let’s see if this kind of post works out.

Last week was my first week back at work after a few weeks of vacation. So an important part of my week was catching up. Going through emails and chat messages. Talk with my fellow team members. Participate in the usual meetings. Some stuff that didn’t make it into this post. More importantly, there are three things I did, that give a good idea of what a significant part of my job looks like.

Read more…

A question I don’t seem to be able to let go of is: where does a tester fit into a software development team? More specifically, how essential are testers to the team?

I think that there are basically three options:

1. Your testers do not add something essential.
2. It’s not clear if your testers add something essential.
3. Your testers do add something essential.

Your testers do not add something essential

I suspect this is becoming more and more common. Thanks to Agile, CI/CD, DevOps, improved tooling and changing expectations, you should not have testers that find the dumb bugs I was expected to find at the start of my career. If a programmer wrote a > where it should have been a >=, we should expect a unit test and not a tester to catch it.

Read more…

level 0: no one takes notes

Few things confuse me as much as being a meeting with no one taking notes. Is everyone’s memory so much better than my own? Is what’s being said just not that important? Are people fine with only retaining a few things and nothing else?

Luckily I’m not alone. Johanna Rothman seems to agree with me, at least for essential meetings:¹

If a meeting is essential, it will have an agenda. It will have minutes. It will have a list of action items, and someone will manage them so that people are accountable for their action items.
- Modern Management Made Easy by Johanna Rothman

That’s why it’s level 0. There’s no reason to ever be at this level. Borrow some pen and paper. use your phone. The least you can do is take notes for yourself.

Read more…

Earlier this year I posted about how I implemented a counterstring function using “fake it till you make it”. I also posted about different ways to implement counterstrings. In this post, I want to share how those different implementations compare performance-wise.

To do this, I used both Tinybench and vitest bench (which uses Tinybench). The results are basically the same, but their default output is slightly different.

The nine implementations

Before I present the results, I should describe the different implementations and how they differ from each other. The actual code of each implementation is available on GitHub. Here I’ll only mention what makes each implementation interesting compared to the others:

Read more…

This is the third post in a three-part series about my statement “The difference between a test case and a requirement is the moment of discovery.”

Last year I wrote about how the difference between a requirement and a test case is the moment of discovery. And how that means that we should be intentional about our exploratory testing. Exploratory testing is just one example of a bigger idea, though: optimizing for moments of discovery.

So what does that mean, optimizing for moments of discovery? Don’t those moments just happen? Isn’t that what serendipity is all about? I think it’s fair to say that you can’t make moments of discovery happen. You can make them more likely to happen. That you can optimize for.

Before I go into two practices to optimize for these moments of discovery, I want to talk more generally about moving the moment of discovery, either earlier or later, for both requirements and test cases, i.e. for design and test. Because the two practices will do exactly that: moving the moment of discovery.

Read more…