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…

A few weeks ago someone suggested we should start measuring how many automated test cases versus how many manual test cases we have. Luckily it was part of a longer list of suggested metrics and it was also presented in that way: a list of options, to be discussed later. And the reason I say “luckily” is because I knew I disagreed with using that metric, but didn’t have a good explanation as to why. At that moment I could have given a minutes-long monologue about how that metric doesn’t fit how I think we should be thinking about testing. However, I have zero expectations that such a monologue could have worked in that situation. It would be all over the place as I philosophize about testing and make all kinds of connections and analogies. A convincing argument that does not make.

So since then, I’ve been thinking: how would I explain my position on measuring manual versus automated test cases? Something to the point, something relatable, something that acknowledges the need behind asking for this metric. And then it hit me: use cooking as an analogy. Now I know plenty of people have made this analogy before. However, I don’t remember reading everything I will cover in this post somewhere else. Also, there’s value in different people saying similar things, but each in their own voice.

Read more…

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…