The Automation Dance

Testing is merely the flip side of programming in the sense that both programmers and testers are simply trying to anticipate the actions of the user. Programmers do this to anticipate users' needs. Testers do it to make sure the thing doesn't blow up or catch fire. But in either case, there's an element of the fine art of second-guessing involved.

Around the Dr. Dobb's offices, I do a bit of this myself. I handle a few odd bits of automation in our publishing process here, and so much of that task is about second-guessing the inputs to my processes. This is the fine line we all walk when we try to automate complex processes: We tread the boundary between what is possible to automate, and what absolutely requires the input of a human.

My particular automation guessing game involves converting the print Dr. Dobb's Journal articles into HTML. You'd think this would be simple. You'd be wrong. Why it's not simple is a long, long story. But part of it has to do with the very unpredictability of inputs that make both programmers and testers crazy. You just can't write code that can deal with every possible permutation of inputs. The moment you think you've got every case covered, you will inevitably be faced with a user action or a piece of input data you just didn't think was possible.

The only way we can deal with it is to accept our limitations, and make some prioritized choices about what to automate. In other words, automate the things with reliable inputs, and clear the way for the quickest possible human intervention for the things with unreliable inputs.

Posted by Kevin Carlson at 01:22 PM  Permalink