Is Ours Not to Reason Why…?

Posted: December 30, 2012 in Testing Skills & Education

NOTE – I’ve struggled putting my thoughts on this into something beyond a “rambling, incoherent” vomiting of scramble.  Hopefully some part of it makes sense…

Being able to effectively investigate, replicate and document bugs in a black-box sense are key skills for a tester (and anyone who doesn’t think so “is a bum”, to mis-quote the venerable Bob Hawke).  But regardless of the level of a tester’s “bug investigation” expertise, most testers can recall instances where lengthy investigations of a bug have caused a lot of blood (most likely “figurative blood”… well, I hope so), sweat (quite possibly literally… especially in warmer climes) and tears (most definitely actual tears of frustration).  And while we’ll never be able to entirely avoid those nightmare (and rather wet) scenarios, it stands to reason if we can get better at trouble-shooting, we can get better at tracking down what went wrong when “it” went wrong.

But how much do you invest in developing your trouble-shooting “muscles”?  I ask this in two senses – on a case-by-case “micro” level, and on a larger “macro” level.  Macro-wise, the answer seems almost too obvious – as much as you possibly can afford to!  The tester who can proficiently trouble-shoot complex system issues has a significant advantage over his less problem-solving-oriented fellows.

When it comes to the case-by-case level, the answer is somewhat less clear.  Positively murky, in fact.  Probably because the answer changes, funnily enough, case-by-case.

In my current position, I’m able to get at the SQL tables, views, functions and stored procedures that comprise the application’s back-end.  Over the past few years I’ve developed a reasonably good understanding of SQL.  Sometimes I’ve worked the problem out.  But I’ve also spent many a half an hour (or longer) working through a myriad of linked views or breaking down complex formulas to track down a bug.  After finally conceding, I’ve then watched the developer spot the problem and fix it in about 30 seconds.  Over time (and watching the developer work his develop-y magic), a few heuristics have coalesced into being.  But these are situation-specific, and I’m still yet to establish a “larger / universal” approach capable of effectively attacking the many kinds of problems that pop up daily.

Trouble-shooting is something testers do in an almost day-to-day capacity.  But although most of us would have rudimentary skills in this area, it doesn’t necessarily make us much more effective when it comes to dealing with problems than the man off the street.  The business philosopher Jim Rohn said (and this is heavily paraphrased) “when you say you have ten years’ experience, it doesn’t necessarily mean that.  You might just have one year’s experience repeated ten times”.

SEMI-ASIDE – That said, this may be why support people tend to “fall” into software testing a little more – they have developed some form of trouble-shooting skill (to a lesser or greater extent), and coupled with the extensive domain or application knowledge most support staff, the skillset forms a potentially potent pairing for prosecuting powerful… tests (sorry, couldn’t think of a P word to round off this masterpiece of alliteration).

Tangents, detours and distractions aside, effective trouble-shooting is a topic I’d like to explore much further at some point in the not-too-distant future*.  Are there heuristics, methodologies or processes out there that pertain specifically to trouble-shooting?  What good books are there on problem-solving?  I hope to be able to answer these questions in the next few months…

*Yes, it’s something I’d like to be looking into now but have quite a backlog (currently working to apply the myriad of excellent lessons from Elisabeth Hendrickson’s “Explore It”).  Do I need to prioritise this?  Should I prioritise this over other aspects of testing I’m playing with at the moment?  Hmm, that requires some consideration…


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