Ever since I started working back in 2006, I’ve used a notebook. Initially, I didn’t have a system, I just wrote things down. Then, about seven years ago, when I became a scrum master, my notebook became more important. As a tester, I could use my team’s board to keep track of my work. As a scrum master, none of my work was on the board. And even though my role has changed several times since then, my need for keeping track of things hasn’t.

So somewhere along the way - and to be honest I forgot when exactly - I created my own system of note-taking based on bullet journaling. It’s simple and straightforward. It helps me plan my day, list possible future actions, and keep a record of what I’ve been doing. On the one hand it seems like something small and simple. On the other hand it has been a major help to me, so I figured it’s worth sharing.

Read more…

Several weeks ago I had a thought that felt both serious and not serious, so I asked on Mastodon:

Should I write a blog post about companies leaving money on the table by not leveraging their choice of work management tool (Jira, Shortcut, etc) as a competitive advantage?

31% said “yes” and 54% said “a post about what now?”, which I suppose reflects my own feelings about the topic. And it motivated me to write this post - especially that 54%. So let’s talk about work management tools, the original (user) stories, affordances and constraints, and how these tools are limiting our imagination.

Read more…

At the end of chapter 4 of “Clojure for the Brave and True” there are four exercises. This post is about me deciding to move on to chapter 5 after solving 1.5 of these exercises.

The challenge with these exercises

A good example to talk about the challenge with these exercises is the second one:

Write a function, append, which will append a new suspect to your list of suspects.

Read more…

Three months ago I started a new job as a quality engineer, supporting two teams. So far it’s been an interesting challenge. The two teams were formed only a few months before I joined, although some team members had been working for the company before that. Each team has their own product manager. We also have an engineering manager, but he joined only two weeks before I did. And then I was added to the mix, with a job description that didn’t give a lot more guidance than: support the team in things related to testing and quality.

So my first task in my new job was figuring out what my job was. Or rather, figure out what concrete things I could do that fit that job description. This was not made easier by the fact that we’re a fully remote company. Not being in the same space throughout the day does make things harder when you’re trying to find your place. Reflecting on the past three months made me realize there are three things that are really important: visibility, connections, and patience.

Read more…

In her article “Better Testing, Worse Quality?” Elisabeth Hendrickson makes an interesting case about independent testing, i.e. testing done by an independent test team. She discovered that beyond a certain point, investigating more in independent testing will make both quality and speed go down, not up. In episode 3 of the Idealcast, she summarizes her article as follows:

“[…] when you ramp up the amount of investment in an independent test group, then given the amount of pressure that’s already on the developers to deliver, it is so easy¹ for the developers to say, this isn’t my problem anymore. Thank goodness we’ve got the professionals over here. It’s their job to test.” (00:11:21)

Later in the article, Elisabeth Hendrickson gives advice on how to avoid or escape this spiral of decreasing quality and speed. There are four dials you can turn either up or down:

Read more…

For years when asked to define quality, I’ve said “value to a person who matters”¹. Not too long ago I used that definition in the first post of my four-part series “Thinking about quality”. However, in the fourth post of that series I also said that quality is something emergent. And I continued with:

We can have long discussions about what quality is, but that’s a different question from how do you get quality?

Today I took this one step further, when I realized that depending on the context, I talk very differently about quality. And while I may not define ‘quality’ explicitly in every conversation, implicitly I’m still using different definitions. That alone, I think is interesting: instead of a single, general definition of quality that always applies, I have different definitions depending on their purpose².

Read more…

Last week Elizabeth Zagroba asked on Twitter:

If someone was completely new to working on software on an Agile team, what would you want them to read about Agile first?

My first thought was: “The Agile Manifesto!” After a second thought, though, I reconsidered and replied:

And I would recommend against reading the Agile Manifesto without consulting any secondary sources, except if you read it in the same way as you would visit a historical site “just to see where it all happened”.

As I wrote this, I could not really put my finger on why exactly I felt this way. The best I could come up with was that the Agile Manifesto is hard to understand on its own. You need some historical context and practical experience to make sense of it. Serendipity came to the rescue, though, as I’m currently reading Seeing Like a State by James C. Scott. Chapter 9 of the book focuses on the Greek concept of mētis (μῆτις) and how it relates to rules of thumb. Turns out that this explains why the Agile Manifesto is a poor introduction to Agile.

Read more…

Yesterday I came across a post on LinkedIn explaining why there are no testers in Scrum¹. What struck me most about the post was the amount of work the word “tester” was doing. In one sentence it meant one thing (a role in a team), in the next sentence something else (a step in the process), and so on. Hence the title of this post: the word “tester” was being used as an overloaded variable. So let’s do some unpacking.

Testers to people management

“Having a tester” means that there are people with the official title of “tester” or “QA engineer” or whatever within the company. For the purposes of people management², there’s a distinction between this role and the other roles in the company. This allows for more specific expectations about the role, for different career paths and salary scales, etc.

Read more…

The past month I’ve been thinking about risk-based testing. This post collects three thoughts on risk-based testing I kept returning to.

If not based on risks, then based on what?

About a month ago I tweeted:

What are the alternatives to risk-based testing?
Requirements-based? I’d argue that’s a subset of risk-based.
Unguided? That’s either a bad idea (“we hope to get lucky”) or aimed at the risk of unknown unknowns.
Any other options? Because something about the term is bothering me.

My question was inspired by the “opposite” heuristic from my talk about testing types: if we have some kind of category, what’s the name for the things not in that category? Applied to risk-based testing: what’s the name for testing that’s not risk-based?

Read more…

In my previous Clojure post I covered the code example at the end of Chapter 4 of “Clojure for the Brave and True”. Or rather, I focused on a single function in the example, called mapify, and described how I figured out what it does. At the end of that post I shared my disappointment:

Having done all this work (and writing) I can’t help but feel a bit disappointed. In the end, the function does not seem to do a lot.

And I shared a Python version of that same function, claiming that it basically does the same thing¹.

However, less than a week after publishing the post, I got a very kind email by someone named Martin. And “in defence of clojure and to maybe reduce your disappointment” Martin pointed out the two versions are not as equivalent as I claimed, because the Clojure version is more general than the Python version. So I looked at the two version again and the way they are different turned out to be quite interesting - interesting enough to write a follow-up post.

Read more…