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.
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.
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.
Because when all you have is a sonic screwdriver every problem looks like . . . well, it could look like anything, really. 😉
One mobile you can’t escape GUI Automation – http://testautomation.quora.com/Why-you-need-*GUI*-automation-in-mobile