I have recently joined the Ministry of Testing Bloggers’ Club, which aims to encourage its bloggers to blog, and to blog better.  The first topic we’ve been suggested is a technical tip every tester should know.  This seems a bit like Radio 4‘s Just a Minute, where you are given a topic and then have to talk for 60 seconds about it without hesitation, deviation or repetition.

I will try to avoid the first and last points, but I fear I will deviate a little.  I’m not a tester, so I don’t feel qualified to give them advice.  Also, I think that my tip is not all that technical.  But it is a tip!

The tip is to do with automation: do something manually before you automate it.

What first?

There seem to be several things we should be doing first in modern software development:

• Digital first
• Mobile first
• Content first

Not forgetting the things that need to drive everything, and so need to be first:

• Unit tests (TDD)
• Acceptance tests (BDD)

I have my own addition to that list, to do with my first job, relating to automation:

Do it with phones first

I’m not proposing that you get your mobile out before you do anything – I will need to explain a little.

A trip down memory lane

My first job was with a company that did things like phone banking and auto-attendants.  The auto-attendants were small PCs that would physically plug into phone sockets where phones would normally go, and then receive incoming calls and route the calls to the correct destination.  At the centre of the system was the switchboard, and the PC would talk to the switchboard by sending signals to it over the phone line.

You could send the same signals from an ordinary phone handset, and the details would vary by switchboard.  The signals would be an arbitrary sequence of things like a quick hang-up, *, # and the numbers.  Getting the details was a chore, but something we had to do whenever we met a new switchboard.

My mentor gave me a bit of advice that has stuck with me ever since:

Do it with phones first

Before plugging in the PC and fiddling around with your code, just plug in 3 phones and make sure you can do it manually first.  Once you’re sure of the details, then you compile them into your program, plug the PC into the switchboard and try testing it.

Where this applies

How can this anecdote be applied if you’re not plugging PCs into switchboards?  The point is to automate late rather than early.  This can apply to many things, but in my experience it has applied to:

• Testing (hence the link to MoT)
• Deployment
• A complicated data processing pipeline of ETL tools, stored procedures etc.

I think that there are exceptions to this rule, such as code compilation, but it’s worth remembering as a general rule.

Benefits

There are a few benefits to automating late:

It is often quicker to change a manual process than an automated one.  While you’re still working out the details, you can often get to the final set of steps more quickly if your experiments are via a manual process.

You will probably gain a deeper understanding of the process if you’ve done it manually first.  Automating puts code between you and it, which can insulate you from learning about it.  If things go wrong or you need to change things in the future, having a proper understanding of the automated thing will help.

If there are unexpected results is it because of the thing, or because of the automation of the thing?  If either the thing or its automation are flaky, it can be hard to home in on the actual cause.

It takes time to automate.  Automation can produce a nice shiny toy that generates dashboards and saves time, but is the saving greater than the cost of establishing the automation?  There might be other benefits to automation, like quality, but regardless there is a non-zero time cost to automation.  Is this bit of automation really the best use of your time?

Think about automation early

While you should often delay automation, you shouldn’t delay thinking about automation.  Just as one of the benefits of TDD is that it forces programmers to think how their code could be tested, I find it’s helpful to think how a manual process could be automated while I’m experimenting with the process.

What will trigger this thing?  How will I know when it has finished?  How can it go wrong?  How will I tell if it has gone wrong?  If it goes wrong what should and shouldn’t happen?  What do I need to know about when it’s successful?

These are all important questions to answer before automating, and it might be possible to shape the process while it’s still manual in a way that gives better answers for automation.

Conclusion

Automation is a tool like many others we use.  Knowing when to use that tool is important, but even more important is knowing when not to use it.  It can be tempting to start automating early, but this temptation should be resisted.  Automation should happen when it is the best thing to do next, when its costs are outweighed by its benefits.  Keeping automation in mind while you’re developing and using a manual process will help reduce the costs of automation when you finally use it.