Tag Archives: software


A cautionary tale about software testing (and cheap kitchen drainer baskets)

We recently bought this for the 2toria towers kitchen.

It’s….a kitchen drainer basket thing.  The one we had before was plasticky and rubbish so, whilst out shopping a couple of weeks back we saw it for a low price and decided to replace our old model.  It was a steal at about £2.99!!

And, it’s great.  It holds dishes and even has a handy plastic container bit that you can clip on to any corner.  Practical and useful – it does what it was intended to do.

Only problem is, it has a flaw.  If the plastic compartment is loaded with cutlery but there are no plates, it does this:

There was no safety note about overloading either…

This is a BIG problem, as you can imagine.  It doesn’t hold nearly enough things!!

The reason behind this post isn’t to tell you about my poorly designed kitchen drainer basket, but to highlight the potential of bad design and a lack of user testing when building anything (although I’m using the analogy for software development really).  When the original plans for this were put together, it probably looked great on paper, but the designers did one of two things:-

  1. They didn’t actually test their prototype before releasing for bulk manufacturing.
  2. They did test it, found this flaw, and decided to build and release anyway, assuming that users would just figure it out for themselves.

Either is a pretty bad thing.

Seriously now, I know it doesn’t matter too much in this case – after all it’s just a kitchen drainer basket. Imagine however that this was software and situations 1 or 2 came about. The compartment could just as easily be an interface to a database, or a routine that deletes or inserts records, and if that was flawed or untested things could really go wrong. It has happened before, and will happen again – some extreme examples can be found here (although admittedly not all are entirely the fault of poor testing).

The takeaway from tonight’s silly little story?  Test the things you develop before you release them into the wild.  Get your users to test them, and then test them again yourself.  Try to think of every possibility – try to break what you’ve just made in every way you can think.  Test until you can test no more, until it gets completely boring, and then test again.  If there is something wrong that you didn’t spot when your product is eventually released, let your users know what to do (or not to do) and (if possible) provide a workaround until you can fix the problem.  Do fix the problem however, and as quickly as you can.  Then, test that the fix works, and then test that your fix hasn’t unintentionally broken anything else.

Got it?  Here ends the lesson.

(There are lots of resources online about software testing, and too many methodologies to discuss in such a short post, but this Wikipedia entry is a pretty good starting point if you want to learn more.)


Buy off the shelf, or develop in-house?

In organisations there is often the question raised as to whether software solutions should be developed in-house (if you have the right people with the right skills, that is), or bought in.

My question to you is what do you think is best?  Feel free to post comments if you have more to say.

Develop, or Buy?

No answers available.
Internet Web Links

Really useful website – all your favourite software downloads in one executable file

If you’ve ever had to reinstall Windows you’ll no doubt know what a pain in the backside it is getting everything set up the way you want, especially when it comes to installing all the essential bits of software you need (eg Web browsers, messaging, audio players etc).  Ninite.com makes life that little bit easier and lets you combine multiple software installations into one easy executable so you don’t have to clog up your hard-drive with numerous files.  Just select the apps you want from the one page list and click ‘Get Installer’ and you’re off.