AUTOMATION 1 - The guide

First off - thank you so much for the overwhelming response I've had to not just my last piece, but a previous piece but one earlier in the year looking at common issues in automation.

One thing is clear, automation isn't going away, and we wouldn't want it to either.  But at the same time, we want to encourage responsible thinking and use, something which can be sadly lacking.

The purpose of the next series to come is to provide a framework to introduce a lot of the ideas around automation.  I'm going to try and put them through in such a manner that they build a story, build from each etc.

The Readers Contract - please reread

Don't worry this isn't a super-long one, but I like to think for this series I'm entering into a contract with you, dear reader.  This series will cover some key concepts, and will try to cover them well, but not in depth.

By necessity there's a limit to how deep I can go (remember I blog outside of my work life, I'm not a full-time writer yet), and I really encourage you to go deeper than the source material - as with so many things Google is your friend.  Because I'm writing an introduction, be aware that I'm also slightly simplifying some ideas and concepts a bit to make it easier to understand.

Regarding using information on the internet - remember there is some misinformation out there.  However, if you're enough of a reader of this blog, then your critical thinking skills should be sharp enough to read an agenda or when someone is trying to sell you something - use your "spider-sense" well.

Defining automation

As with everything, definitions are important to make sure we're on the same page.  Automation, and especially test automation is a loaded term, which people use without really thinking about much.

Wikipedia says: "Automation or automatic control, is the use of various control systems for operating equipment"

a control system to operating part of software, together with a feedback mechanism to check any output is as predetermined.

I find that semi-helpful, and there's lots to debate in that thread.  Indeed, if you've got time, read the whole page.  For me, the definition I'm going to use (for checking automation) is,

"Automation is a scripted control system which allows us to operate a software component, and includes a feedback mechanism to check the output is a predetermined"

You will see in future installments, that this definition is extremely important to understanding how to automated, and it's limitations (I know this, because I've read some of those future chapters already - being the author has that kind of benefits).

The Iron Laws

In writing the series I've identified three iron laws of automation, which I'll state upfront, and will be referred to as we explore more.

Right now, I'm not going to explore these any futher, but as we go through, I'll be highlighting them as we go along,

LAW ONE: Reduce your check to a simple pass/fail result to be useful

LAW TWO: Be maintainable to be reliable

LAW THREE: Embrace simplicity over complexity to be effective and efficient

Going deeper

If you've got time, look around different definitons of automation on Google.  Don't just be limited to those which say "test automation".  If you can, read all of that Wikipedia page.  Have a go at writing your own definition for automation, and if you like, share it with me below ...