The Pilgrimage, pt.1


It’s cold. Damn cold. I keep telling myself that if you’re suffering a bit, you’ll appreciate warmth, a good meal and friendly people even more. But how much abuse is the right amount?
It’s ‘the beast from the East’, also known as Russia’s cold wind, vs. the beast from the South, also known as me. It’s a fight I’m pretty sure I won’t win, but I’ll settle for survival. I’m equipped with a folding bike and four bags containing all I need.
At the end of it all, there’s a treasure worth ploughing through the snow for…


Test. Bash. Brighton.

The reward to be found at the end of this trip, will be in the warm arms of my tester friends as we hug, drink, laugh and inspire each other to become better at whatever we do. I say whatever, because I keep being astonished how we’re still so inherently different, value other things and pay attention to varying topics, yet somehow feel connected through our passion for quality & testing. If there’s something I’ll be keeping my eyes open for on my adventures, it’d be these wonderful moments of finding the unexpected, different views on the same thing. Test the world, as you will.

My cycle down will not be uneventful. RiskStorming in Edinburgh (though cancelled), img_20180228_181440.jpgRiskStorming in Cambridge and a workshop in Brighton. There’s a Grumpy Tester, Del Dewar, waiting for me in Edinburgh who’s opened his home to me.
I keep being amazed how supporting and caring the Testing Community is. I struggle to phrase exactly how much I appreciate it. That’s why I support Ministry of Testing in all their ventures. They make this happen.


The Route

The plan is to cycle North-West to a Scottish national park called Loch Lomond & the Trossachs to reach Glasgow. Take the train from Glasgow to Carlisle and cycle through Lake District to Manchester.
From there I’ll cross Peak District to end up in Nottingham, then Cambridge, London, Brighton.

Don’t know where I’ll sleep for most of the times, don’t know which route I’ll take, but I’ll manage and I’ll enjoy. One thing you can count on is the resourcefulness of a human being.
Yesterday I had a lovely ride from the airport to Del’s. Crossed a windy bridge and icy forest-y roads.


Product Owner of Test Automation


2018 is another year of change for me. I packed everything I needed in 4 bags that fit my bike and on the morning of the 3rd of January started pedaling south.
Tom Waits – Whistle down the wind in my ears.


Wind in my back, sun in my face. It felt as if something beckoned me, helping me forget what was left behind.

Car, house, job, security, city, comfort, relationship… everything was sacrificed. At least for now. In return I got freedom and a different kind of comfort. I can do whatever I want, enjoy what comes my way and seize all the wonderful opportunities that would otherwise make me think twice.

Since then, I’ve arrived in Munich, a bustling city. Met with QualityMinds, a wonderful company and rejoined with friends who showed to be more than true to the name.
Vera & Marcel have been absolute angels. Supporting me by opening up their home, workplace, baking birthday cake, being motivators and listening to my stories. Vera even found an ideal job for me.

Product Owner of Test Automation

A change in roles comes with an interesting set of insights. I had never been a Product Owner before, nor is my technical prowess in Test Automation of much note.

I do have a knack for connecting people, empowering people and strategising in function of change. Because of this, I’m sure I can add value over the coming months. In my years of being a tester in a SCRUM team, I figured out that the nature of the Product Owner role is hands-off, enabling and providing feedback. However, what I didn’t see before was the effort it takes in finding out how to balance the following:

  • What needs to be done to satisfy our stakeholders in the short term?
  • What can be done within the current constraints?
  • What does the team like to do?
  • What does the team need?
  • What can we do in function of the long term vision?

I feel a tension between now and later, us and them, needs and wants and I like the implications this has. It means my reporting and communication needs to be better. It means I need to listen as much as I talk. It means that I need to direct now to have others evolve later.

Personal introspection and (hopefully) progress, I love it.

For now, I visualise myself sitting at a table on which a massive boardgame is displayed. I’ve only just gotten to know the other players. This game has been going on for some time and I’m the new player. I see the cards I hold and plan for success whilst guessing for surprises that will sweep my feet from under me. I plan now to act later, slowly positioning allies, empower certain areas and planting ideas in the other player’s minds.
The path to victory lays before me, but so are the hazards and changes.

A good strategy goes a long way, but needs hard work, luck and support from others to succeed.

The Strategy

Phase 1:

  • Become a functional SCRUM team that adds value by means of either added confidence or fast feedback.
  • Build a stable and maintainable checking framework as a team.
  • Build a strong relationship with Stakeholders

Phase 2:

  • Coach and strengthen automation practices throughout the development life-cycle by example.
  • Support Testers through handy tools and automating the boring stuff.
  • Provide compelling data and reports to stakeholders who need to make decisions.

While a Strategy is rather deterministic for now, the tactics will certainly change over time. My first challenge is in splitting up the base tactics into workable tasks. Secondly, listening to the team on how they deal with this and how they would move forward.

I’m anxious to find out how things evolve from here.



Session Based Learning

Software Testing

Last week at BREWT1, a peer conference in Belgium, I was talking to Simon Tomes about an idea his new tool TestBuddy had triggered:

Session Based Learning Management.

Let me first introduce you to Simon and his project. Simon is a wonderful human being who’s mission in life is to raise the spirits of everyone around him just a little bit higher. With years of experience, he’s become pretty darn effective at it. #GoEncourage is his mission to see things positively and communicate as such. As a tester, he’s found it especially helpful for his developer-tester relationships.

TestBuddy is his Simon’s and Rajit Singh‘s brainchild. From the way thin

gs are looking, this will become the go-to application for Session Based Test Management. Centralising your charters, your missions, your team and giving an overview of what’s done and is still on the stack. I’ve had the privilege to watch their journey and am eager to see it evolve further.


What do we have to learn

The idea that sparked me to talk to Simon was that their tool could very effectively be ‘abused’ to guide team learning.
Imagine being on a team that kept a backlog of ‘what do we have to learn’, the same way we have charters that guide us in ‘what do we have to test’. Same concept, different goals.

Imagine sitting in a planning meeting that would outline skills, information, books, videos,… that must/should/could be explored. Having those ‘learnings’ split up in charters that work the same way as you’d test an application:

Plan your learnings:

  1. As a team, pinpoint a skill, piece of knowledge,… needed by the team
  2. Explore the skill to get a basic overview (a first charter?)
  3. Outline what the absolute basis is to start building from
  4. Identify what outside help/tools/resources you need
  5. Try to plan a step-by-step pathway of learning consisting of several charters

For every charter:

  1. State your mission of learning and describe what a successful session would look like
  2. Whenever you see opportunity to have a sidetrack, create a new charter for it
  3. Use the time of the session to learn in function of the charter mission.
  4. Debrief with the team: What have you learnt and what can you teach?

Using Jon Bach‘s PROOF model:

P: How did you go about your learning journey?
R: What can you identify as having learnt?
O: What stood in the way of learning?
O: Did you see sidetracks or uncover new steps to explore?
F: Does the learning path still feel valuable? Would you abandon/change/evolve the pathway?

Notice how the process guides you through different learning phases?
Explore, Draw, Internalise, Debate. 

I could see a wonderful learning path for the whole team using this method. In the long term, there’s nothing making us happier than to learn something new.

Working together to gather new insights, collaborate on setting learning goals and sharing acquired knowledge,… I image would be an incredibly strong psychological, emotional and fulfilling journey for any one team.

What do you think? Could this be something you could apply in your project? How much time would the team be able to invest in this per day, week, sprint?


Tired of Answers

Complaining, Software Testing

During the past few years, I’ve interacted with many experts, thought leaders and emerging talent and boy, there’s plenty of them. I mean this in a non-comical way, there is tons of talent, keep your eyes open and ears cleaned (this was meant comically).

Regardless of where I am in the food chain of conference goers I can’t help but observe, learn and… among other feelings; get frustrated.
The thing that has been baffling me for the longest time is that people come to conferences, fora, slacks and: ask questions. That’s not the crazy part. This is:

People expect simple answers and crazier yet, they get them.

Here’s why that’s preposterous: You are working in a complex situation. Everything is subject to change. Nothing is certain to be static. Assuming it will be, is risky.
That’s the only given we have.

But how many people deal with that given, feels so very wrong.

We cut the problem into many smaller ones. We like that. It’s easier to understand. Less brain intensive, more straightforward to plan for and very manageable.
It’s a common engineering pattern. Imagine you’re on the team tasked with building the Golden Gate bridge? You look at designs of other bridges, work out how many bolts, nuts and bars you need and get setting them together.
That sounds easy, right? Except that something in the back of your mind is telling you it probably isn’t. Nobody has built a bridge of this magnitude before. This task might be more complicated than initially thought…

On top of that add the the following parameters:

  • The water it crosses is not a river, but a bay. Subject to the tides and rapid weather changes.
  • The political and territorial landscape might change.
  • Vehicles crossing the bridge will inevitably evolve, maybe even much sooner than anticipated.

Compared to other bridges, this one is proving to be a complex beast. As soon as we take the holistic view, we realise how wrong we were.

Here’s a secret. We’re all building complex beasts. We don’t understand the fundamentals, we can’t foresee the future, we don’t know our present well enough and we have no idea which parameters will change our situation today, tomorrow or just after the next major release.

Therefore I would advise everyone to quit looking for simple answers. They are false.
Therefore I would advise everyone to quit giving simple answers. You are not helping.


There are principles, models, sets of guiding rules, methodologies, approaches, tactics, heuristics, practices,… and many different ideas to help you do a better job.

Some of these can help you greatly, most of them were created and defined with good intentions but ALL of them have been misunderstood and/or misused by malicious or irresponsible actors. (including myself, at times)

The next time you’re faced with the need of giving or receiving simple, easy answers, repress that urge. Instead try to trigger thinking. Within yourself and within others. Thinking deeper, broader and in different directions. Offer alternative ways of thinking, provide helpful information and ask questions that may lead down a path.
The path of learning.



Applied heuristics

Experience Reports, Software Testing

This is an experiment. I’m trying to figure out my understanding of what the word ‘Heuristics’ means to me and whether it’s helpful to me and my craft: Testing.

Therefore, I’ll rehash an old story of how I found a bug and annotate the heuristics used in Bold and see what I can analyse from that afterwards.

Any guidance, ideas, intuitions, sources are very much appreciated.

Finding a Memory Leak

It was past noon. I’d been testing an application that wasn’t too complex for quite a long time. I knew it’s ins and outs and I felt myself getting bored.
I remember going through the customer files rather methodically one by one, click,… click,… click , without a clear aim. You could say I was randomly exploring.

Until something didn’t feel right. Call it surprise, intuition, something was wrong.
I noticed a pattern of loading times slowing down almost unnoticeable. I can’t put to words what triggered it for me. Was it an Observer-expectancy effect? Was it my negative mindset that sharpened my senses? I haven’t got a clue, but I felt I had to focus, zoom in.

I chose a tactic that was less boring than meticulously clicking my way up. Selenium IDE isn’t the best of tools, but it fit my purpose perfectly. I recorded my click and copied it a thousand times. I monitored the behaviour with developer tools, pressed ‘play’ and went for a coffee. After a while, I could identify that it went terribly slow because I could see the latency increase. Eventually I saw it ramping up until it crashed. Pairing with a developer we could conclude that there was a serious memory leak.

Implicit and Explicit heuristics?

A heuristic is “A fallible approach to solve a problem”

The teachings of RST and BBST and possibly how ‘heuristics’ were meant in the science books would identify all the bold phrases as some variation of a heuristic. I’m sure many other heuristics played in my mind that I don’t have words for yet.

However, notice how the first part of my story is almost completely based on hunches and feelings. Something directed me to find this bug and it wasn’t intentional.

In the second part, I took matters into my own hand. I had a goal, I chose a tactic and was able to measure my results. Other tactics, could have been clicking the button myself for the umpteenth time and miss out on a coffee. I might have asked a developer to look into it straight away and maybe had time left for two or three coffees.

I can’t know for sure whether I chose the correct heuristic or tactic for that situation and I’m sure as hell “# of cups of coffee drunk” isn’t the correct way to measure that success.

We can’t go back in time and compare results of heuristics used vs. the ones not used. Though I’m pretty happy with the results of the one I set up.

The Question Remains

Are the ‘Implicit heuristics’, (i.e. feelings, patterns, biases, hunches) which can’t really be controlled, measured,… useful to call heuristics? They fail, yes. They help you notice things, yes. But do they solve problems?

Are ‘Explicit heuristics’, (i.e. repetition to find boundaries, monitoring for abnormalities, pairing to increase understanding) worth a dime without their implicit counterparts?


It’s not up to me to answer these questions. Yet I find it intriguing to ponder over the matter.