Over the past year, I’ve been thinking about how testing-related roles are still an unsolved problem in software development. We keep trying different permutations: shifting left and shifting right, being closer to the programmers while not too far from other testers, doing less testing ourselves so we can support others more, etc.

And still, to be effective in any of these permutations, you can’t let yourself be limited by them. You need to work both inside and outside the existing structures. You have to “be all over the place”, in a good way.

Testers do testing

Let’s start with a straightforward statement: a tester tests. Then what is testing? I still like the definition “Testing is investigating in order to evaluate a product.” The most obvious thing to investigate, to test, is the code that is being written. The best way to do this, in my opinion, is through the combination of exploratory testing and test automation, i.e. what Maaret Pyhäjärvi has named “contemporary exploratory testing“. And to be clear, while the execution part tends to be the most visible, effective testing also needs good test strategy, design, and reporting.

Read more…

On September 9th I facilitated a session at the FroGS conf open space titled “Agile history, it matters, right?” My main goal was to get input on where to take my Context of Agile site. Before asking for that input, however, I asked the participants three questions about the history of Agile. I figured it would provide a good introduction to the topic. And I was curious how much the kind of person that joins a session like this, knows about the history of Agile. So a big thank you to all the participants!

The three questions about the history of Agile

The three questions about the history of Agile were:

• When did Agile start?
• What lightweight methodologies were represented at the Manifesto meeting?
• What did the software development look like that Agile was reacting against?

Read more…

At the end of my first week at my last job I published a Notion page that started with:

Inspired by “The agile comms handbook” I’m experimenting with a weekly (internal) blog. No big promises on the content, just the things I feel like writing about at the end of my week. And as this is an experiment, things might change along the way.

Please feel free to add a comment, respond to other people’s comments and/or share with others!

In this post, I’ll tell the story of my eight-month experiment with weekly notes. After that, I’ll share some tips in case you want to give weekly notes a try too.

Read more…

During our latest monthly call, Maaret Pyhäjärvi and I spent some of our time discussing agency, accountability and scrum masters. At one point I said something along the lines of:

Scrum masters often end up as scrum mascots.

Maaret said I should write a blog post about scrum mascots¹, so here we are.

According to the 2020 Scrum Guide a Scrum Master² is accountable for two things:

• “establishing Scrum as defined in the Scrum Guide”.
• “the Scrum Team’s effectiveness”.

Accountability implies (or rather: should imply) corresponding authority. You’re being held accountable for certain outcomes *and* you have sufficient power to influence those outcomes. That’s a scrum master. A scrum mascot is a very different beast: they have neither power nor accountability. And yet that seems to be what a lot of organizations (and scrum masters?) want.

Read more…

Recently I applied to two scrum master jobs and it got me thinking: what is a scrum master? What is it exactly that they do?

What made this question even more pertinent to me (apart from the job applications) is that in the past I have been a scrum master. But that was five years ago and none of my jobs since had much involvement of a scrum master. And my experiences of those past five years made me wonder: where exactly does a scrum master fit in?

A scrum master is the Scrum boss

The 2020 Scrum Guide says:

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

Read more…

Chapter 5 of “Clojure for the Brave and True” explores two core concepts of functional programming: pure functions and immutable data structures. It wraps up with walking you through the code¹ of a game called “Peg Thing”², which uses “everything you’ve learned so far: immutable data structures, lazy sequences, pure functions, recursion - everything!”

So what is this Peg Thing?

For a full description and the code of Peg Thing, you can follow the links in the paragraph above. In this post I’ll only share what’s relevant to describe what I learned about functional programming through Peg Thing.

Read more…

This post is a slightly edited version of the experience report I presented at the xp2023 conference. It covers my first six months at a scale-up, working as a quality engineer for the first time - after having worked in other testing-related roles for 15+ years.

My main finding is that for a quality engineering role to work well, certain structures need to be in place. The most important one is that the impact the quality engineer is expected to have, is clear to both the quality engineer and the team(s) they are supporting. However, regardless of which structures you put in place, a quality engineer will also need to work around those structures to be fully effective.

Read more…

Too often I’ve heard people say: “Oh no, not another meeting!” Usually this means they feel their time at work is split between time in meetings and time in which they do actual work. And to be fair, they have a point. I too have been in plenty of meetings that didn’t achieve much of anything. It doesn’t have to be this way, however. Meetings can be effective and they can leave you with a real sense of having accomplished something. And in this post I’ll explain how to make that happen.

We struggle with meetings

We struggle with meetings. On the one hand we keep proposing them, scheduling them, attending them. On the other hand we keep complaining about them. We feel sorry for people with a day full of meetings. When a meeting ends early, we “get 10 minutes of our lives back”.

To that I say:

If you feel you do all your work outside of meetings, you’re meeting wrong.

It’s something I realized while I was a scrum master: my work happens during meetings. Mostly team meetings and 1-to-1s. There’s prep before and follow-up after meetings, but I did the core of my job through meetings.

Read more…

Recently I realized there are a few testing questions I use a lot. They lie at the top of my testing toolbox, so to speak. Together they shape my testing style, making it easier for me to discover certain things, but probably also harder to find other kinds of things. So here are my five favorite testing questions, in no particular order.

What if there are zero, one, many, lots of this thing?

Last year I expressed my surprise on Mastodon how many times I’ve found bugs by asking the question: “What if there are 0 / 1 / several / lots of this thing?” And if you’re working closely enough to the code, you should also ask about “null”.

Quite a few people responded to my message. Turns out it’s a very common pattern in TDD. And Brian Marick¹ remembered it standing out when he was looking into fixed bugs in the Linux kernel they used in the ‘80s. Personally I learned it from Elisabeth Hendrickson’s “Test Heuristics Cheat Sheet”, which found a new home last year at the Ministry of Testing.

Read more…

Originally Scrum was very much about “You tell us what needs building. We’ll decide how we build it and how soon we’ll deliver.”¹ I’ve never seen that version of Scrum. The version I have seen, has a product manager try to get as many features into a sprint as reasonably possible - for varying degrees of reasonable. This comes at the expense of maintenance work, such as keeping libraries up-to-date or removing technical debt. And it incentivizes the team to cut corners on features, to not leave code in a better state than they found it, to not fix smaller bugs and instead log them somewhere for later.

One solution I see to this problem, is to put an engineering manager fully in charge of the team.² The product manager prioritizes the features. The engineering manager prioritizes the full scope of work for the team. That’s not a simple change to pull off, however.

Another solution might be to change the way we use our backlogs. If a product manager gets to prioritize all the work, and the tool they use is a backlog, then we should make sure that all the work³ is in the backlog: features, bugs, and technical debt. Let’s take a look at each of these three categories of work.

Read more…