Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it. And then he feels that perhaps there isn’t.”
— A. A. Milne, Winnie-the-Pooh (1926)
This quote and illustration comes from the opening paragraph of Winnie-the-Pooh by A. A. Milne, first published in 1926 — the very first book in the series. The bear is introduced as Edward Bear, his formal name, before he becomes more commonly known as Winnie-the-Pooh.
This is one of my favourite illustrations from the Winnie-the-Pooh books. Perhaps an unlikely source of inspiration for improving how we work — but it captures, with disarming simplicity, what it feels like when we’re stuck in ways of working that no longer serve us.
It can’t just be me that feels like this about our work. And I don’t just mean testers. I’m sure we can all think of situations where life feels like this.
Bump, bump, bump…
We’ve always done it like this…
But surely we don’t have to?
Yet change is hard. It requires deep thought and consideration…
And we don’t have time for that…
So we go…
bump, bump, bump…
again and again.
Bump.
So here we are, trapped in a never-ending cycle — running faster and faster, yet never seeming to actually get anywhere.
I’ve often felt this way about testing. When I first started out, I knew no different, so I had to fit in with what I’ll call traditional testing — an approach that often reduced the discipline to a tedious checkbox exercise. No wonder few people wanted to do it.
Over time, I learned how to play this to my advantage, which enabled me to build a consulting capability and rapidly grow into senior roles. Right from the start, it didn’t feel like the right way to do things. But I didn’t know any better. The ISTQB taught me that this was how testing should be done — so that must be right… right?
This tension came into sharp focus on a consulting assignment. Using an ISTQB Fundamental Test Process model, I vividly remember having to justify a £250k, eight-week testing phase — about a third of the total project cost. It got spicy, with internal management and eventually the client’s senior executives. To my credit, I got it approved.
Whilst this felt like an achievement, deep down it didn’t sit well with me. Surely we could achieve the same — or better — outcomes for our clients for less money and in less time?
If only I could stop bumping for a moment and think.
This isn’t a new problem. Software engineering has been around for well over half a century, and I believe the challenge of producing high-quality software, cost-effectively, has been solved — that knowledge just isn’t evenly distributed yet.
Many people have gone before us. They’ve done the thinking, tried different approaches, and shared what they’ve learned — in books, blogs, and talks. They’ve refined their approaches through feedback, debate, and experience. And if the problem hasn’t been solved in the software quality space, it’s likely to have been solved in other fields.
The real challenge is finding what helps us — seeing the wood for the trees. Among the huge amount of advice available, how do we tell the difference between ideas that genuinely move us forward and those that simply sound sensible, safe or familiar?
In our industry, we’ve long accepted there are no best practices — no universally correct ways of working — because everything depends on context. And your context is almost certainly different from mine. All we can do is look for good practices, then experiment to see what works — until our context changes and we start again.
It’s a bit like heading into the Hundred Acre Wood on a treasure hunt. Scattered around are countless jigsaw pieces from countless puzzles. Our task isn’t to complete someone else’s picture, but to find the few pieces that help us create our own — a picture that evolves as we learn and adapt.
In this blog, I’ll be sharing what I find on that journey, and what my picture of good software quality and ways of working looks like.
Hopefully, my reflections will be useful to you too.