Over the past few years, I have been an ardent, arguably minority voice stating my skepticism about the value of GUI-driving test automation, developed by someone other than the developers, after the code is "complete."
At the same time, I've admitted that the reality of an increasingly technological society will mean that, while we may not all need to be SDETs, we'll need to be more technical simply to participate.
Then something happened that threw me for a loop.
Have you ever been on a project like this?
The scope is huge, the deadline is impossible. Someone gives the bad news up the chain, along with logical reasons, not just plain pessimism.
... and the message is actually heard!
The manager of operations steps up and offers to have his team run the files by hand. Hey, it's a new product, there won't be that many files to start with. Even if there are, we've got a thirty-day processing window. No worries.
Hit the deadline with all the other features, and you can build the import program after go-live. How about that?
Now, there are a lot of ways this can go wrong, but in this case, I'm not complaining about a over-eager manager who commits to something he can't do -- I mean the manager actually can do it. He does have the resources, and, even if he didn't, he can call upon the resources to bring interns and temps and entry-levels to get the thing going. For once, someone took responsibility, and it was a responsibility they could accomplish.
This is a very good thing.
... time passes ...
The project deadline comes
You ship. On time. It works - it actually works!
Then the manager steps in, and assigns his right-hand to import the data.
It goes well.
There is not fighting. No finger-pointing. No missed deadlines.
Curious, you ask in a meeting how she did it. I mean, you import the tables into Excel, but then what?
She looks at the group and says "Oh, no problem, I just wrote a little program in
SPSS to get the data in the right shape. We really only need to upload daily totals at this point."
What. Just. Happened?
The customer's own analysts are writing programs.
Perhaps those programs need to be tested, perhaps there are shortcuts involved, perhaps the Software Development group would make it automatic and now it takes four manual steps a day -- the point is, the customer is writing code.
Everyone is writing code.
No, Virginia, I do not think we all need to become programmer-testers and strive for 100% automation of the GUI, see a greenbar for our build, breathe a sigh of relief, never to explore.
But I do think that we will be writing tools. Driving drivers. Getting behind the GUI and driving the API and the business logic.
Orchestrating services, writing scripts.
They may be throw-away scripts; we may be changing them all the time, and there may be people who bring other skills, like subject matter expertise, to the test project that don't write code.
But, for the record, when I said in a technological society, we need to raise the bar, I meant it.
My great hope is that the best ideas in software testing win.
I'll see you out on the playing field?