How my Testers help Me


In the beginning of last year, I moved from a Test Consultant to a Product Owner role and I haven’t written much since. Gaining so many insights over that period from: My role change, remote working teams, testing strategy workshops in other companies, Agile transformation of a HealthCare company and much more. It’s been a tumultuous year, but a rollercoaster in learning and insights. The end of the ride is not in sight.

My first insight I wish to explore is how I, as a PO, am dependent on testers: My in-team tester, our automation specialist and the separate team of testers.

In my role, I am mainly concerned about delivering a quality product that people are sufficiently happy with. It shouldn’t be stellar. It doesn’t have to be perfect. It has to be an improvement. 

That’s the context I work in. We’re trying to replace a big monolith of ancient software into smaller pieces of understandable, working software using strangling patterns.

A strangling pattern in short: You identify the boundaries of a piece of functionality, you build a completely, separate duplicate of the functionality and feed the exact same inputs to both pieces of functionality in a test or production environment. Then you monitor the outcomes. When, over time, the outcomes are consistently the same you can replace the old functionality with the new.

This pattern is used in situations where functionality has become so complicated, so bloated that any change can cause a ripple effect across the software destroying just about anything.


Team Day in the mountains

The Team Tester

Given this situation, I rely highly on the software testers. My team’s tester has been working for the company a lot longer than I have and has a wealth of knowledge when it comes to the application and its history. That’s why me and the team need him to:

As Early As Possible:

  • Warn us about possible points of failure;
  • Inform us about potential risks and their outcomes;
  • List problematic parameters and outliers that we might forget;
  • Talk to & prepare other testers about the changes that are coming.

During Development:

  • Support the team by providing information, good and bad, about the current state of the product;
  • Inform the PO about the progression on achieving of sprint goals or not;

After Development:

  • Support me in handing over the changes to our most direct stakeholders;
  • Hand over the changes to the separate test team so that they can see what actually was finished.

In other words, he’s a bit out guardian angel. Not the kind to swoop in and save the day, but the fairy-god-person type that’s always watching our backs and supports us to overcome problems ourselves.

The Automation Specialist

To be honest, when it comes to automation on the service or UI level, it’s not profitable for us yet. Our specialist has her hands full maintaining old selenium scripts for the big monolith. Voices constantly rise up whether these scripts are worth the investment time and again. For now, we persist.

Next to the maintenance, she’s also involved in pair development with the others in the team, learning about implementation new user stories. She’s involved in pipeline improvements and team discussions about for example: the depth and effort the team wants to put in TDD practices and so on.

With our move to Windows containers for our test systems and hopefully also production, she’ll have her hands full supporting the team in providing checks and information on stability.
For I want them to streamline everything so well, that in the future they can give me a button: a button that I can push at any time, that deploys our current devbranch into production.


OktoberFest, with the Alps in the background

The Separate Test Team

This is a whole different article that needs to be written. Potentially, this is the point in the Agile Transformation that has had the biggest change and effect on the reliability of our releases of all.

In the past year, I’ve seen our releases go from “Always going horribly wrong, needing four to five hotfixes” to “A release with scheduled hotfixes” to “A stable release with little to no problems.”
These changes can be attributed to changes across the whole development process, but it is a marvel to observe how much more efficient the test team has become.

I saw them, under guidance of great test consultants, abandon most of their documented test scripts and develop mindmaps and checklists. They focused on efficiency, speed and supporting rather than complaining, defending and acting like martyrs.

To Conclude

The testers I work with cover a lot of ground. They focus on results and moving forward, by amplifying the team through information. Information that is actionable and valuable.

It hasn’t always been like this. Together, we’ve come from a very ‘structured’ process where people were working in separate roles on a monolithic software problem, making our situation worse and worse by the day.
What turned it around was:

  • Problems being made visible;
  • Protection being provided by (and from) management;
  • People’s roles being mixed;
  • Teams getting a vision, but otherwise left to their own devices;
  • Relentless positivism;
  • Strong consultants that support with knowledge and learning.

Little change after little change each of us started to see a little light in the darkness. That’s all one needs to keep moving forward. So we joined hands and started in that direction together.


Part of the team, chilling

A Changing Mindset

Experience Reports, Software Testing

Ever since I left my short stint at the meat factory, I’ve been a Software Testing Consultant for all of my modest career. Until a few months ago, when fate threw me into a Product Owner role.
5 months in, I feel my priorities, my thinking, my mindset… change.

This is not necessarily a good thing, but it is a necessary thing. First, I was Product Owner of Test Automation. But as that team disbanded due to too much overhead for a reasonably small team, I became Product Owner of a 8-headed SCRUM team of developer-architects, a tester, a test automation specialist, a DevOps specialist and soon a new junior developer.

My previous two blog posts were about helping a relatively small team learn more, move them forwards and become confident.
My new role is again different and it’s providing me insights about myself, how I adapt to these dynamics.


My mindset has changed drastically. Where I was focused on risks, oversights and possible problems before, I am now looking at ‘good enough’ and going forward with the things ‘that matter’. Because of my Testing background and my now PO role, I realise that those two things are very different for me than other team members. I don’t know the risks well enough, I don’t know the scope too well (as the product is very new to me) and I can only guess at the value our changes bring.

Yet, this doesn’t seem to stop me forming opinions and making decisions.

It frightens me to take steps forward into this vast uncertainty of unknown unknowns knowing that I’m probably on top of the Dunning-Kruger ‘Mount Stupid’.
I caught my self disregarding several risks people mentioned, just because they intervened with my plans…
I have critisised many Product Owners before, when I was a tester, that I could see they had no clue what they were doing or where they were going.


I’m beginning to believe that this uncertainty is a big part of the role.
I need a tester to keep my feet on the ground.
I need this done as early as possible.

My priorities lie with keeping the team happy and delivering business value to the stakeholders. Not in risks, maintenance or changes…

Because of that, I’m not thinking of 3 out of 4 types of work.

Four Types of Work

When you find yourself in a situation where you don’t know enough or feel inadequate, start learning, reading and discussing. That’s what I do at least. I needed to ‘up my game’.

One extremely important finding for me were the four types of work featured in ‘The Phoenix Project’: Business Projects, Internal IT, Changes and the highly destructive Unplanned Work.

This connected several frustrations of mine into one model.
My current customer is quite good at pinning down Business Projects. At the very beginning, we do a three-amigo kind of thing where we lay the fundamental vision for the project and immediately try to cut down all the surrounding waste.

Internal IT is handled reasonably, though the responsible people seem to live on a well frequented island. We have two Admins who seem to troubleshoot and fix several major problems a day.

Changes are frequently happening, but are largely unmanaged. I’ve added a blank User Story in our sprints to capture ‘surprise tasks’. This should create a good baseline to see where these change requests come from and how much time they soak up. From there on out we can create procedures to mitigate, ignore, prioritise, escalate… What exactly we’ll do with the data, I don’t know yet, but we’ll have a better idea on how to tackle these changes.

I finally can put into words why I as a tester was often a source of frustration for a Product Owner: Unplanned Work. This type of work disrupts your whole flow, motivation, plans and ultimately, can destroy your project. Call it, bugs, risk, oversights,… it’s everything that suddenly requires someone’s attention and who can therefore no do anything that was planned. It eats your plans. It tears apart your flow and energy. It makes sure people get frustrated.

When Work In Progress is often called the silent killer, Unplanned work is the loud bloody zombie apocalypse that comes to exterminate your project. It terrifies me.
… enter the jolly testers who tell us we forgot about something important.

We just had two sprints torn up by the walking dead. Project management: ‘oh, we forgot to include these highly crucial features that need to be in production by the end of the month.’
Nor I, nor the team, was amused.

A Change in Thinking

A year ago, when I was a tester in this situation I would raise many bugs, make them visible and be loud about the frustrations I could notice in the team.
In similar occasions, I’d have given up and watch the train ride into a wall (again) to then see what we could make of the pieces.

Being in this situation as a Product Owner I try to make the best of the situation. Hope for the best and try to plan for the worst.
As a contingency, I put machinations in place that will bring more insight:

  • We will capture the ‘surprise tasks’ that weigh on the team to manage Changes
  • We will analyse the bugs found after development (and initial testing) from the past 6 months to build a checklist that can help us identify Unplanned Work
  • I need to keep a buffer to allow for Unplanned Work

The data in 1 will be a baseline to come up with certain Change Procedure(s).
From the data in 2, we can build automated checks, monitoring, alerts and ‘have you thought about/talked to X’-checklists for management.

I’m now in a role where I don’t have to be the 20-something-year-old screaming bloody murder anymore. It might sound strange or unfair, but my words have more impact these days. I won’t complain.
This phenomenon has given me the power to actually strategise and bring change while being very obvious about it. I’m not trying to persuade people to follow my ideas anymore. I’m gathering them by being direct.

I want to avert future disasters like we’re now in. I want the team to be on top of things. Maybe in the future, we’ll simulate our own disasters, while we’re still in control. Just for fun. And learning.


Product Owner of Test Automation 2

Experience Reports, Software Testing

In my previous post, I explained the strategy I envisioned for the team. Comparing it to a boardgame.

What this post lacked thoroughly, was a clear focus on team learning. I feel like an idiot for not noticing this earlier.

Learning Objectives as part of the sprint

What has become abundantly clear to me is that the Team Members are the heart of your team. They need to be nurtured, grown.
In our team, we’ve been actively investing into people to become more confident and knowledgeable. ‘Learning objectives’ have become about 50% of our sprint stories.

I add in: Spikes, Proof of Concepts, Blog Posts, Challenges,… to have people work through material and produce reports, concepts, demo’s or anything that reproduces the acquired knowledge. After that, they ask feedback from other team members, discuss or teach. The aim is to achieve two things: new learnings and something valuable for the team, project or product. This keeps our stakeholders happy and our team in learning-mode.

But 50% is a lot of time… how do you explain this to stakeholders?
Test Automation is a valuable endeavor. Though in uncertain conditions it can be rendered useless, time consuming or time wasting even. That’s where we are now with the team. Many different things are changing. The application, the architecture and the development teams are all getting a good shake. This is not a good moment to heavily invest in UI or even API checks. Instead, I shift the focus of the team in a different direction.

Whereto now?

I see a lot of opportunities to coach, train and pioneer automation strategies, as a team.
Once the dust settles from all the management decision-making and architecture workshops it’ll fall on the automation people to strongly improve our release pipeline.
To achieve this, we need to become better at what we do, need to become more confident in what we say and become more respected for the value we bring.
As a team.

Instead of building more automation, our focus shifts to coaching, training and knowledge sharing. The issue, however, is that we first need to do knowledge gathering and train ourselves. The good thing is, we’re more of a team now than before and we can help each other out. We also have some time to invest in ourselves, which will pay off tenfold in the future. Hopefully.

In congruence to the team building up their skills, I’m monitoring progress of these changes and looking for opportunities to help out. Whether it’s now or in the future, I want to know where we can add business value fast. Additionally, I’m collecting examples of good practices in our context and using those as a basis to build an automation strategy.

Changes are coming our way, but we’re preparing to deal with them.


The Automation team, at sprint kickoff



We had just enjoyed a great night of RiskStorming in Cambridge, some pizza, beer and the company of  a nice group of expert testers trying to solve the same problem at the same time.
The workshop went rather well. I figured I wanted to try out something new this time and focus the RiskStorming format on a sprint-level change. Instead of focusing on a specific application, we looked at a new feature that would be added to an existing app already.
This is something more lifelike. You’re in a sprint, a new feature is proposed and you’re asked to come up with a plan to test for it. Turns out RiskStorming deals pretty well with this refocus as well.

We ended up in the pub afterwards and that’s where my toothache hit me hard.

Long story short: I was crippled by throbbing pain for 2 days. The first one I spent in Karo’s spare bedroom, the second on my bike to London.

The pain was thundering like a drum inside my head and I was pedaling to the beat.


To London! I don’t care if I haven’t prepared a thing! I NEED TO GET RID OF THIS PAIN!
Not having a plan is normally not a problem if you go anywhere else but London.

This time, it got me into a halfway house… I think.
Riding in London with a big, packed bike is dangerous. More dangerous than the snow-covered Scotland I had just left behind.
Looking for a place to stay in full youth hostels gets you laughed at, apparently. Until I met one guy who’d ‘do me a favour’. He took my money and sent me to a house down the street, which is supposed to be part of the youth hostel. It wasn’t listed on Google maps, I wasn’t able to find a website or anything but the front door.

People seemed nice, but didn’t talk to me and looked, sounded and smelled as if they’ve been living there for some months now.
After barely sleeping, I left at 7 in the morning. It’s also where my teeth started swelling.


Taking the train from London to Sevenoaks, because I prefer hills, forest and nature over big buses, traffic lights and fumes. From there I cycled through a beautiful piece of the UK. I quite loved both the North and the South. The middle, except for Lake District, isn’t very exciting to say the least.





As by chance I visited the coffee and gift shop that was home to one of my very favourite heroes: Winnie the Pooh! On this empty plate was an waffely, vanilla iced goo topped off with Maple syrup.


A final AirBnb in the forest, felt like home and had a nice warm bath for me.


My tooth didn’t hurt anymore, the days were spent in the forest and up-and-down hills. Rather uneventful, but damn beautiful.

I arrived. Brighton. TestBash.

During my journey I’ve had some bad luck. But I was able to cope with it. The most important part is that I learned and learn I did. Putting things in perspective and looking at exactly what changed for me is for the next coming weeks.

Thank you for following my pilgrimage, if you’re at Brighton, let’s have a talk!




The Pilgrimage, pt. 3


Having gone through Lake District, I took the train to Nottingham for a bit of a rest and some working days. Just like Del’s home was opened for me, the coming nights were spent in the wonderful company of Constance, Neil Studd, Neil Younger, Shey, Mark and Karo.


A new quote for Constance’s fridge

The testers I got to know over the years turn out to be real friends, who open their doors, welcome me with open arms and check up on me and my travels afterwards.
I feel very lucky to have such people in my life and I try to give back as much as I’m given.

Vegan for two days

In Nottingham, with Constance, I was mostly working in coffee shops and following to her Vegan lifestyle. I was worried about energy levels and my bowels adjusting to quality foods for a second, but I’ve enjoyed it thoroughly. By Constance’s tips and guidance, I found incredible cakes, burgers and pizza’s, served in the vibrant scene that is Nottingham. Which seemed to be a bustling city, but not very beautiful…


The road from Nottingham to St. Neots, however, was brightened by godrays.

The South

From there on out, I made my way partly by bike and partly by train, to St. Neots, where I met with Shey and his lovely family. If you had the pleasure to meet Shey before, you know he’s a ball of energy and really connects people at the party. I could now see where all that positive energy comes from. Shey’s wife and kids are so incredibly empowering, active and kind. I absolutely envy Shey for having fostered such a beautiful family. I had felt a similar boost at Del’s though conditions up North were different.


Surprisingly, Neil Studd also lives in St. Neots. We had a lovely evening in the pub where I discovered some local beer and ‘pork scratchings’. Both were… interesting. I finally was able to get rid of my Scottish pounds after charming the 50-year-old barmaid. Apparently, nobody in the South wants currency from Scotland… Which is actually the same currency. No wonder this country is going down the Brexit path.

Spending the next day working with Neil, we went to two coffeeshops and eventually, his homebase, as screaming kids seem to follow us across town. If you want to know what Neil’s home looks like, picture shelves with videos. Shelves with videos. Also quite a nice interior in which the shelves with videos fit nicely. He showed me his bookshelf, which was filled with videos.
Having had an amazing breakfast and lunch at a charming coffee shop where Neil seems to be a regular, I felt strong enough to move onwards to Cambridge, where the next RiskStorming was organised.


After a night at a guest house and another day of work, I found the incredible group of Cambridge testers ready to partake in Pizza-eating, Unicorn-destroying and beer-inhaling… and some RiskStorming too of course!


And then,… the Toothache hit me. Hard.