Not too long ago, and not too far away, I was a software developer for an insurance company, and I worked on a system called filemover. Filemover was, well, an application that moved files. How it did that was by monitoring directories for new or changed files, so that, for example, when a trading partner dropped a set of claims, or electronic enrollments, onto our servers, it could take some action.
The action was different by filetype, but generally involved moving the file from one system to another. Filemover also might make log entries, send emails, kick off some sort 'import' batch job -- you get the idea.
Once a month or so someone would need to promote some code from a test environment to production. When they did that, the software would move servers and filesystems, and the transfer and import would move from something hand-keyed to something that had to happen automagically.
And, when that needed to happen, they would call me.
"Matt", they would say, "We need Filemover to move files named something like stc-import-yyyy-mm-dd.txt from hither to yon every monday at 8AM." I would ask them the standard set of questions:
From what directory and machine, exactly?
To what directory and machine, exactly?
Straight file copy or FTP/SCP 'transfer'?
(If it's a transfer, what's the useraname and password?)
Zipped or unzipped on either side?
Are there any semaphore files or other race conditions involved?
Do you need a backup file dumped anywhere, or special logging?
You get the picture.
Now conceptually, people should have included filemover scripts in the requirements for the software. In practice, the filemover work was so small that it was easily forgotten. So the company "just" carved out some percentage of my work to deal with filemover issues.
So here's a typical scenario: Around Thursday afternoon, a developer or project manager would burst through the door, excited and anxious at the same time. "Heusser!" he would blurt (for this late in the project, it was always last name, never first.) "Heusser! I need a filemover script for the giganti-calc project. We move to production on Monday!"
So I'd go through the template.
Originating system? "The test box is jabar. I dunno what prod will be."
Deployed system? "Somewhere in the bowels of ginsu. I don't even have read access to that. I dunno the directory."
User to use? "prod00"
Password? "they don't tell me the production passwords!"
And so it would go, back and forth. If I was lucky, he'd know a third, maybe half of what I needed to deploy the software.
Sometimes the person would partner with me to find the information. Sometimes they'd simply expect me to know it. But every once in a while, a flush would slowly form on their face, they'd get a bit antsy, and they'd say something very much like this:
"I don't know how to move the production file. If I did, I'd just do it manually for a few days while we figure this thing out. But I don't know how to do it manually; that's why we need you to automate it."
Slow down.
Pause.
Reflect.
Er, Um ... What?
Automation doesn't do things for us we could not imagine; instead, it takes a well-defined, straightforward, repeatable process and makes it run at the press of a button. In other words, if we don't know how to do it manually, we
can't automate it.
Sometimes, when I hear about test automation, I feel a little bit like I'm working on filemover. Here we are, trying to solve a complex problem that is only vaguely understood by writing code, when we might be better off investing time and effort into first understanding what testing is and how to do it well.
Now I can't say for certain, but when teams ask me about automation, I may begin to reply by asking them about the state of their existing testing. And, instead of recommending test automation, I may suggest they
become extremely good at what they are doing now.
When's the last time a test automation guru said that?