Skip to main content

Quality in a Jar

Its an oft chanted mantra that software quality can be 'baked in'. Like flour or eggs you just mix in the right ingredients and out comes perfection. If my wife and I were ever to take part in our own bake-off, then you'd soon see that hypothesis undermined. We'd both begin with the same ingredients, oven, spoons etc. My better half would no-doubt deliver another scrumptious banana cake and I - a new and interesting exterior wall sealant [not my intention].
Batteries and LEDs, but no quality.

The problems here are manifold, There's a Reification error, for quality is not a tangible entity (A favourite issue for Michael Bolton). There's the idea that once built software and its use is immutable. If you've ever had to use one of those unmaintained applications (typically a time sheet/billing system) thats gone to seed you'll agree that it hasn't exactly aged like fine Claret. But what's most naive is the assumption that the simple use of a tool or ingredient will make some thing better - it'll make the bugs go away and stay away.

People and consequently software is more complicated than that. A problem with a piece of software can be almost anything from an incorrect conditional operator, to the use of an incorrect language dialect  e.g.: I had the pleasure of testing some navigation/directions software, developed in the USA, as it was being 'tweaked' to work in the UK. A good example of an issue was an instruction along the lines of: "Take the off ramp, then rotary 1st exit". To a British English speaker that sounds more like instruction on how to skate-board while donning a wristwatch than how to navigate a junction (sorry 'intersection')

The tool, is just that, a tool and is nothing without the artisan's skill behind it. In testing, it is the testing skill involved that matters over the particular software tool or library installed.  To highlight the oddness of the proposition, Transplant the situation to another team member and see how it fits: Does the programmer with the most feature rich-IDE automatically produce the best code? or wider afield, Would you trust a bad doctor with space-age tools more than a skilled and experienced doctor and his judgement as to what tools and instruments to use?

Just adding a test tool, a Jar file or executable, and robotically implementing checks in its prescribed format does not automatically give you good software. Further-more, approaching a testing problem with the tool in-hand, biases you greatly as to what problems you are going to find as well as possibly miss-directing you away from the problems.

   "When all you have is a hammer, all problems start to look like nails." - Mark Twain

For example over-using Selenium or WATIR for testing a feature rich GUI is a common mistake. Many companies standardise on such a tool for GUI test automation. If your application is heavily GUI driven, then that's important to bear in mind. Your feature-changes are human user oriented - so testing could well benefit from well errh more 'human user' interaction.

The most powerful tools are your eyes, brain and hands. Let these take a look first, get an idea of where to apply the tools and what those tools might be. Don't expect that just installing that Jar will bring automatic improvements.

PS: You can learn more about those 'Sun Jars' here: http://www.comfycamping.co.uk/Gear/Lighting.aspx

Comments

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: