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

Post a Comment

Popular posts from this blog

Can Gen-AI understand Payments?

When it comes to rolling out updates to large complex banking systems, things can get messy quickly. Of course, the holy grail is to have each subsystem work well independently and to do some form of Pact or contract testing – reducing the complex and painful integration work. But nonetheless – at some point you are going to need to see if the dog and the pony can do their show together – and its generally better to do that in a way that doesn’t make millions of pounds of transactions fail – in a highly public manner, in production.  (This post is based on my recent lightning talk at  PyData London ) For the last few years, I’ve worked in the world of high value, real time and cross border payments, And one of the sticking points in bank [software] integration is message generation. A lot of time is spent dreaming up and creating those messages, then maintaining what you have just built. The world of payments runs on messages, these days they are often XML messages – and they ...
Post a Comment
Read more

Text to SWIFT - making data from prose (What possible use could Gen AI be to me? - Part 2)

 As I write this, my dog is grumpily moving around the room pausing intermittently to give me disappointed looks - looks that only my elderly mother could compete with. She (my dog) is annoyed by the robot vacuum cleaner. Its not been run for a while in that room - and its making a noisy foray into dark corners in a valiant effort to cleanse the mess. Its grinding gears and the cloud of dust in its wake is not helping to ease the dogs nerves. The dog's pleading puppy dog eyes & emotions have of course been anthropomorphised - at least a bit - by me (My dog is 7 years old and weighs over 20kg - so has little to fear). That is - I've taken human feelings and mapped them onto my dog. I know she has emotions - but she lacks language - or at least a language that (1) we humans understand, (2) maps to the same phrases or concepts I'm using. But I'm human, That's how I think and how I interact with people and sometimes - machines. Deciphering the problem and representi...
Post a Comment
Read more

Don't be a Vogon, make it easy to access your test data!

 The beginning of the hitch-hikers guide to the galaxy leads with an alien ship about to destroy the Earth, and the aliens saying we (mankind) should have been more prepared – as a notice had been on display quite clearly – on Alpha Centauri the nearby star system, for 50 years. Seriously, people - what are you moaning about – get with the program?  The book then continues with the theme of bureaucratic rigidity and shallow interpretations of limited data. E.g. The titular guide’s description of the entire Earth is one word: “Harmless”, but after extensive review the new edition will state: “Mostly harmless”. Arthur Dent argues with the Vogons about poor data access This rings true for many software testing work, especially those with externally developed software, be that external to the team or external to the company. The same approaches that teams use to develop their locally developed usually don’t work well. This leads to a large suite of shallow tests that are usually h...
Post a Comment
Read more