Skip to main content

Fishing for bugs.

You probably don't know, but I'm keen on fishing (Honest! Ok, maybe not, but bare with me...) I spend my free time, by the river bank or out on the sea searching for 'the big one'. The big catch that'll stand as tall as me, and feed my family for a week. My dream is to be the guy standing next to his prize-fish on that black and white picture behind the bar.

Over the years, I've become reasonably skilled. I usually find a fish or two when ever I'm out on the imaginary water. I've learned where they live, where they spawn, and of course where's best to catch them. For example, There's a little bend in the river upstream from my home, that has some great fishing spots. The overhanging rocks protect small fish from the predatory eyes of birds, and people. Of course where there's small fish, there's usually the odd big fish or two.

Ok, lets imagine that fishing had a profitable side too, and wasn't just a [fictitious] hobby. For example, People would hire me to help remove fish from their lakes. It seems that certain large predatory fish can be quite a nuisance, and land owners are often keen to get rid of them. Take last year for example, I was up in Scotland fishing for Pike on the request of a local land owner. The land owner had become nervous after hearing reports of the 6ft man eating Pike, and hoped to avoid any nasty fish related incidents on his estate.

Monday, the first day of my holiday - I set out onto the lake, in my small rib boat: "John Frum". After a hour or so I caught my first Pike. I also found a few smaller fish, but these were not really what I was looking for. But again, my experience reminded me that small fish, might mean big fish are also lurking down in the depths of the lake.

Each day I ventured out onto the lake and each day I found at least one big fish, and somedays two. By the end of the week, the land owner was pretty impressed with my exploits. He was happy that I'd found the fish, and seemed reassured that something had been done about the fish problem. I was happy in my role as 'fisherman' and it felt good to be helping people out.

But then something confusing happened, I found I was suddenly out of work. I was going to have to find another place to [make up stories about] fish for a living. The landowner had decided that he didn't need any more fishing done on the lake, and anyway he'd decided to open the lake to holiday makers the next day. I mentioned the problem with 'man eating pike' and how sometimes they didn't distinguish between who or what they were eating and how this could harm business. But to my surprise he replied "You spent all week fishing the lake, each day you caught a pike and on Thursday and Friday you caught 2 each day".

"Thats my point!" I replied, "aren't you worried?"

"How could I be worried? The fish are all gone, you found them all!"

As you can see, The land owner and I had different interpretations of the same results. I, the tester-turned-fisherman visualises a massive test space of 'lake'. A lake so vast that my puny rod and line only manage to catch fish after extensive practice and hours of work. I see my work as a sample, albeit an intelligent sample that helps find things other 'anglers' have missed. But I don't ever claim to have fished the entire lake clear. In fact the more I find, the more evidence I have of a problem, not less.

The landowner, see's the results differently. He's motivated to open to the public. A confirmation bias is helping him to interpret the results in a positive light. In his view, there are a finite number of problems, and we have removed some of those or at least we know where they live and what they are. The unknown issues, that we might expect given our sample's results, are less visible to him, because of the bias to interpret the results as desired, that is as 'good news'.

Comments

Post a Comment

Popular posts from this blog

The gamification of Software Testing

A while back, I sat in on a planning meeting. Many planning meetings slide awkwardly into a sort of ad-hoc technical analysis discussion, and this was no exception. With a little prompting, the team started to draw up what they wanted to build on a whiteboard.

The picture spoke its thousand words, and I could feel that the team now understood what needed to be done. The right questions were being asked, and initial development guesstimates were approaching common sense levels.

The discussion came around to testing, skipping over how they might test the feature, the team focused immediately on how long testing would take.

When probed as to how the testing would be performed? How we might find out what the team did wrong? Confused faces stared back at me. During our ensuing chat, I realised that they had been using BDD scenarios [only] as a metric of what testing needs to be done and when they are ready to ship. (Now I knew why I was hired to help)



There is nothing wrong with checking t…

Manumation, the worst best practice.

There is a pattern I see with many clients, often enough that I sought out a word to describe it: Manumation, A sort of well-meaning automation that usually requires frequent, extensive and expensive intervention to keep it 'working'.

You have probably seen it, the build server that needs a prod and a restart 'when things get a bit busy'. Or a deployment tool that, 'gets confused' and a 'test suite' that just needs another run or three.

The cause can be any number of the usual suspects - a corporate standard tool warped 5 ways to make it fit what your team needs. A one-off script 'that manager' decided was an investment and needed to be re-used... A well-intended attempt to 'automate all the things' that achieved the opposite.

They result in a manually intensive - automated process, where your team is like a character in the movie Metropolis, fighting with levers all day, just to keep the lights on upstairs. Manual-automation, manumatio…

Scatter guns and muskets.

Many, Many years ago I worked at a startup called Lastminute.com (a European online travel company, back when a travel company didn't have to be online). For a while, I worked in what would now be described as a 'DevOps' team. A group of technical people with both programming and operational skills.

I was in a hybrid development/operations role, where I spent my time investigating and remedying production issues using my development, investigative and still nascent testing skills. It was a hectic job working long hours away from home. Finding myself overloaded with work, I quickly learned to be a little ruthless with my time when trying to figure out what was broken and what needed to be fixed.
One skill I picked up, was being able to distinguish whether I was researching a bug or trying to find a new bug. When researching, I would be changing one thing or removing something (etc) and seeing if that made the issue better or worse. When looking for bugs, I'd be casting…