Auto-Pilot makes the mind go wander…

Posted: August 29, 2012 in Testing Lessons

Hello again.  It’s been way too long.  Life can really get in the way of maintaining a good (or bad, or otherwise – I’ll let you decide which of those this falls under) blog.

My story today is short and slightly saccharine.  It also provided a blindingly obvious lesson I was able to re-acquaint myself with.

I had finished testing functionality to mask credit card numbers that are entered into our company’s transaction processing application a few weeks ago.  It was a pain to test (as it was a small change thrown onto a much larger, more important pile of testing I was already in the thick of), and so I executed “auto-pilot test”, threw the developer what bugs I found, re-tested the fixes and declared it good and proper.  Fin – so I thought.

This morning, the business analyst wandered up and asked a few questions about when the masking was triggered.  I replied with a confident “oh, it only happens once condition X has occurred”, to which she replied “it’s also supposed to happen with condition Y”.  My stomach sunk as I saw, nestled among the relatively short requirements doc, condition Y, in all its finger-pointing condemnation.

A quick jog over to the business manager and a conversation later, and crisis (late changes to this kind of functionality would have been a nightmare with release less than a week away) was averted.  In fact, condition Y was not wanted and would have caused the business some inconvenience had it been implemented.

So the moral of this short testing tale of woe is to not bother about testing against all requirements, they’re probably wrong anyway and you as a tester know better.  Err, well actually… testing on auto-pilot is something we’ve all done.  The conditions and circumstances may differ, and it may or may not have nasty consequences, but it happens.  And when the change / modification /  tweak of functionality appears to be relatively minor and it’s interrupting your testing of “Uber-App 2013™”, it’s all too tempting to give a cursory poke, pronounce “this change/application/update is indeed worthy of release” and move back to the “really important stuff”.

But testing something quickly does not mean testing it without switching on the grey matter, especially those of us who want to excel in our profession.  Testing multiple things at once comes with the territory (when it comes down to it, multiple tasks on the go simultaneously is an aspect of practically every job), and it’s no excuse to flick the auto-test towel at even a tiny something without spending a few minutes gauging risk, thinking about test approaches or engaging stakeholders who might be able to help.  Perhaps even reading through the requirements in full might make a difference.

Until next time, take care of yourself, and each other.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s