Skip to main content

The Hunky-dory Hypothesis

"If we just run it with this data, and it looks Ok, we'll know it works" the architect says expectantly, "Right?"

"You're right, We might see 'it work'", "How would that help?" I answer.

"Well errh, it works, so we can put it live tomorrow."

We've seen this situation before; it can arrive in conversation like the above, or from a review of Acceptance Test results or in a host of other forms. The premise is: everything is fine, we've done the work - we have evidence everything is done and working.

But, how can demonstrating that the application can 'work' help? How will seeing the acceptance test results as 'green' help? That might sound nonsensical, but seriously: how does it help our customer make the decision to ship [or not]? Or help them distribute people and resources better? It may seem that telling them 'its all hunky-dory' is news and good news at that, but it isn't. It can be reassuring, but often it actually harms our understanding of the situation we are in.

Lets take a step back. The code has been pair-programmed, checked by the developers, unit tested and peer reviewed. They believe it's good, their supervisor/reviewer thinks its great. The acceptance tests are all green and emitting a warm fuzzy feel good glow. The project manager, program manager and technical architect are all confident in their designs and plans - they're good - the software is ready to ship tomorrow. The vested parties believe and hence in their view, know, its good to go. A few cursory checks (see above 'test case') is all that is required. So how will confirming their view help? They're already convinced, they already know.

Their view is often the default for programmers, system administrators, those without a testing background or those with a vested interest in seeing the system shipped tomorrow. Their mental image of the software is like a clean sheet of paper, its blank, unblemished, all shiny and new. This spotless canvas also reports no information. No shadows, no ambiguities no feedback whatsoever. If during my testing, I confirm the 'hunky dory' hypothesis, I'm effectively painting white paint on my canvas.

But if during our testing, we find a problem, an area of ambiguity, or an outright bug - We increase our knowledge of the system under test. By filling in these gaps in our knowledge, We are painting a picture of how our system looks under various conditions. This image, albeit a 'Negative', provides the detail that was previously missing from our knowledge. Without this image we are blind to the potential problems and can not see the risks, let alone be able to mitigate them.

Good testing delivers information that helps us disprove our illusions. This process is invaluable in obtaining accurate knowledge of the risks associated with a software release. In a culture where software is considered innocent, until it crashes or loses you money, good testing can help overcome the group-think that often leads to poor software in live environments.

Comments

  1. I've had conversations like that more times than I care to think about. I'm afraid that each time it happens, some folks think that I'm either being pedantic, negative or intentionally trying to ruin their schedule. Excellent first sentence in the last paragraph. Solid post.

    ReplyDelete
  2. It's only a month ago since I learnt that term: honky-dory. And now you've written a splendid piece about it. Thanks, Pete!

    ReplyDelete

Post a Comment

Popular posts from this blog

Why you might need testers

I remember teaching my son to ride his bike. No, Strike that, Helping him to learn to ride his bike. It’s that way round – if we are honest – he was changing his brain so it could adapt to the mechanism and behaviour of the bike. I was just holding the bike, pushing and showering him with praise and tips.
If he fell, I didn’t and couldn’t change the way he was riding the bike. I suggested things, rubbed his sore knee and pointed out that he had just cycled more in that last attempt – than he had ever managed before - Son this is working, you’re getting it.
I had help of course, Gravity being one. When he lost balance, it hurt. Not a lot, but enough for his brain to get the feedback it needed to rewire a few neurons. If the mistakes were subtler, advice might help – try going faster – that will make the bike less wobbly. The excitement of going faster and better helped rewire a few more neurons.
When we have this sort of immediate feedback we learn quicker, we improve our game. When the f…

Thank you for finding the bug I missed.

Thank you to the colleague/customer/product owner, who found the bug I missed. That oversight, was (at least in part) my mistake. I've been thinking about what happened and what that means to me and my team.

I'm happy you told me about the issue you found, because you...

1) Opened my eyes to a situation I'd never have thought to investigate.

2) Gave me another item for my checklist of things to check in future.

3) Made me remember, that we are never done testing.

4) Are never sure if the application 'works' well enough.

5) Reminded me to explore more and build less.

6) To request that we may wish to assign more time to finding these issues.

7) Let me experience the hindsight bias, so that the edge-case now seems obvious!

Google Maps Queue Jumps.

Google Maps directs me to and from my client sites. I've saved the location of the client's car parks, when I start the app in the morning - it knows where I want to go. When I start it at the end of the day, Google knows where I want to go.
This is great! It guides me around traffic jams, adjusts when I miss a turn and even offers faster routes en-route as they become available.
But sometimes Google Maps does something wrong. I don't mean incorrect, like how it sometimes gets a street name wrong (typically in a rural area). I don't mean how its GPS fix might put me in a neighbouring street (10m to my left - when there are trees overhead).
I mean wrong - As in something unfair and socially unacceptable. An action, that if a person did it, would be frowned upon.
Example:
Let’s assume a road has a traffic jam, so instead of the cars doing around 60 mph, we are crawling at <10 mph.
In the middle of this traffic jam, the road has a junction, an example is shown here: