Last Word on the A Word

It’s been a busy month. (I blame Xbox One for monopolizing my time), and I’m way overdue for what I meant to be a “day-after” follow up for my last post. If you didn’t read it (or if it’s been so long you’ve forgotten), here’s the summary and where we left off:

  • “Automation” is an overloaded and abused word that often implies that test code only exists to automate human tasks – that’s stupid
  • If you are a tester who codes, you write code. Period. Some of your code may automate tasks. Most will not (or shouldn’t)

Some have asked if I’m against all automation. My tautological answer is that I’m against bad automation. My better answer is, no – I’m not against automating tasks for some testing. Automation is overused and overvalued in software – while the coding of diagnostic and analysis tools is extremely undervalued. In many cases (quick check of basics, some unit tests, monkey testing, etc.), automating a set of user tasks is beneficial and provides a lot of bang for the buck, but focusing entirely on automation of user tasks is a waste of any programmers time.

I wrote a chapter in a test automation book a few years ago, but on principle, I didn’t write about automation. I wrote about a simulation framework that made it easier to write some targeted automation. To me, writing something like this is a great use of a tester’s time – often much better than to write a suite of automated scripts.

The point is, if your testing strategy is entirely to automate a suite of user tasks, you are doing way more to keep “automators” busy than you are actually providing valuable testing. We can debate the goal of the testing activity, but one thing it is not, is the activity of running through a bunch of user tasks over and over. In fact, one of the touted benefits of automation is repeatability – but no user executes the same tasks over and over the exact same way, so writing a bunch of automated tasks to do the the same is often silly.

I’m done writing about automation for now. I may continue to write about code or debugging or testing. My advice for testers is to worry less about “automation”. Ignore it if you can – but at the very least realize how overloaded…and overblown the word is is the software community and take a holistic approach to software testing.

Similar Posts

  • Are you a game changer?

    I took an internal training course last week where we heard lectures from a bunch of MS execs (I don’t do it justice – it was far more interesting than I anticipated and something I’d do again in a heartbeat). Anyway, one of the lecturers was talking about software markets and showed a diagram that…

  • Stack Overflow

    After my last post, I thought I was done commenting on stack ranking (for at least another year), but two things inspired me to write just a bit more. First, a few people flat-out asked about my opinions for alternatives; and secondly, a consultant added some ignorance to the discussion that gave me just enough…

  • Career++

    Chris Mcmahon once (I think after reading this post) described me and my test role at MS as being like a “tenured professor” – that I have the freedom to choose what I do and choose how I go about it (as long as I show value). I enjoy this role, and think I’ve been…

  • Making Time

    Yesterday, a colleague asked me where I find the time to blog, twitter, etc. This is something I get asked often, but the only answer I have is that I just make time. I put blogging, presentations, sasqag work, and other community stuff right alongside my core work on my todo list. I’m heavily driven…

  • Stop Writing Automation

    After releasing The A Word, I didn’t plan on writing any more posts about automation. But, after pondering transitions in test, and after reading this post from Noah Sussman, I have a thought in my head that I need to share. I don’t think testers should write automation. I suppose I better explain myself. All…

  • Five for Friday – September 27, 2019

    Happy Friday everyone – here’s some stuff to dump from my head to yours. As I type this, I’m listening to Dead Man’s Pop – the remixed version of the Replacement’s Don’t Tell a Soul. I was/am a big Replacement’s fan, and these recordings are all kinds of excellent. This article on how Boeing’s Managerial…

4 Comments

  1. I agree with you completely.

    I also believe that the ability to unblock yourself is required to be a productive tester in most environments today. I don’t see enough of that in testing, no matter if it’s a code based test or a bug. I once had to tell a professional tester “Press continue–then keep testing. We KNOW about that bug now.” Most testers just feel excited that it may be a nest of bugs rather than afraid to move on. I’m imagining 3 years of the person freezing until the 1 bug slot they have in their tiny mind is freed up. It’s like chatting back in the modem days! This is not the Highlander of bugs. There can be more than one.

  2. Agree, too many people believe that just because it’s possible to automate, therefore that you should automate. Automated testing has the potential to be a really valuable tool to assist testing, it’s just unfortunate that the majority of the time it’s the equivalent of using a Sonic Screwdriver to hammer in a nail.

    1. Because when all you have is a sonic screwdriver every problem looks like . . . well, it could look like anything, really. 😉

Leave a Reply to prolificcoder Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.