Testing in a Throwaway Culture

When was the last time that a prized possession of yours broke before its time? Did it make you angry and disappointed?  Were you surprised or were you half-expecting it to break?

Craftsmanship is a word we no longer associate with many of the things that come into our possession.  This was brought to my attention recently when I had to buy a new motor for my very pricey KitchenAid, Architect II dishwasher.  As software quality professionals, we are all on the other side of this.  How many tests were you able to run?  How well did you really vet that app?  Did you understand the app?  How much of your testing went according to plan, however much planning you had?  Did the plan really matter anyway?

Last week, a good friend of mine wrote about his frustration at not having enough time to execute tests because of other test activities such as shaking out requirements, managing others, etc.  I kind of know how he feels because, as the test army of 1, I am responsible for many of the same activities.  I’ve done all sorts of reports and activities that will pad my resume as a QA resource, but, in the end, this is not why I do the job that I do.

Here is a post from Chris McMahon’s blog that is, in contrast, ALL ABOUT why I am very content as a technical QA.  The utter hack-itude of the exploits described in this post are exactly the domain of the tester I try to be every day.  But then, I have the bug reports to fill out, the test planning to create and the inevitable smoothing over of dev ego.  These things slowly but surely chip away at my day.   My friends blog is a description of how, for more senior test professionals, it becomes their whole job, and my friend isn’t the only tester I’ve noticed lately opining the strategy tasks that take up their time ( you know who you are).

We live in a throwaway culture where breadth is valued way over and above depth, and it seems, to me, that this can heavily influence our careers, sometimes for better and sometimes for worse.  This includes software development AND QA.  I’ve worked in this type of environment, not as a tester, as a CM.  I noticed that for every role, CM, tester or dev as soon as people became technical experts at what they were doing, they were expected to start managing whether they wanted to or not, whether they made a good manager or not.  Am I right or am I right?  What’s missing here is an association depth with value both on the technical side and the management side.

What does this mean, specifically, for testing?  What does it mean to be an expert craftsman in testing?  Does it mean that I can switchblade an app with heuristics, any time, any place? Or does it mean that I will find a way to make some assessment of quality if given the most mountainous of systems to test in extremely adverse conditions?  My personal goal is to work hard at both.  I use test management activities mainly as a way to manage DRY (do not repeat yourself) and to get on with the tests.  It’s almost as if there is a sliding scale with test execution at one end and management of test activity at the other end.  This seems a rather one dimensional approach, and careers are not one-dimensional.

When you are asked to stop testing so much and to start managing more, what will you say?  Are you ready to give up depth as a tester and increase your breadth as a manager?  Is this really a one-dimensional issue?  For some, and maybe even for me at some point, this can be a great decision.  In some places, maybe there is less of a tradeoff than what I’ve seen.  For some, participating more in the management process might mean better quality for an entire team.  If the entire team improves, maybe the software will break less.  If the team is testing KitchenAid dishwashers, maybe the dishwashers will break less, and I won’t have buyer’s remorse for my fancy kitchen appliances.

Love it? Hate it?  Comments are always welcome.