Automation in General
Automation means a machine does a task by following fixed instructions, so a person does not have to do each step by hand. The person still decides what the task is and what a good result looks like. The machine does it the same way every time, as often as needed.
This page is about automation in general, not testing. Get this mental model first. Test automation is the same idea pointed at one job.
Automation you already use
| Example | What it does for you |
|---|---|
| Washing machine | Fills, washes, rinses and spins without you standing there |
| Auto bill payment | Pays the electricity bill on the 1st of every month |
| Email filter | Moves every newsletter to a folder as it arrives |
| Factory line | Fills, caps and labels thousands of bottles an hour |
| Phone backup | Copies your photos to the cloud every night while charging |
The shape of every automation
Every one of those examples has the same four parts. Once you see this shape, you will recognise it in every automation tool you meet, including test tools.
| Part | Question it answers |
|---|---|
| Trigger | What starts it? A button, a time, an event |
| Instructions | What steps does it follow? The same ones every time |
| Check | Did it work? Compare the result to what it should be |
| Report back | Who finds out, and how? A message, a log, an alert |
Here are the four parts filled in for the examples above:
| Example | Trigger | Instructions | Check | Report back |
|---|---|---|---|---|
| Washing machine | You press Start | Fill, wash, rinse, spin | Water level sensor, door locked, drum balanced | Beep when done; error code if the drain is blocked |
| Auto bill payment | 1st of the month | Transfer the amount to the biller | Is there enough balance? | Receipt by email, or a "payment failed" alert |
| Factory line | Bottle reaches the station | Fill, cap, label | Camera checks fill level and label position | Bad bottles pushed off the line and counted |
| Phone backup | Night time, charging, on Wi-Fi | Copy new photos to the cloud | Did every file upload? | "Backup complete" or "Backup failed" message |
Automation without the check and the report back is a machine running blind. Nobody knows when it goes wrong.
Why we automate
| Benefit | What it means |
|---|---|
| Speed | A machine does in seconds what takes a person minutes or hours |
| Consistency | The same steps every time. No skipped step because someone was tired on a Friday |
| Scale | Doing it 10 times or 10,000 times costs about the same |
| Any time | It runs at night, on weekends and the moment something changes |
| People freed up | People move from repeating work to work that needs judgement |
When it is worth it
Not every task should be automated. A task is a good candidate when most of these are true:
- It repeats often. Something done once a year rarely pays back the effort.
- The steps are fixed. The same rules every time, with no "it depends" judgement in the middle.
- The input is predictable. The machine knows what it will receive.
- The result can be checked. There is a clear right and wrong answer.
- Mistakes are costly. A human slip would hurt, so consistency is worth paying for.
Tasks that need taste, judgement or a conversation (designing a screen, deciding if something "feels right", talking to a client) stay with people. Automation handles the repeating part around them.
What automation costs
- Building it. Someone has to work out the exact steps and write them down for the machine. That takes longer than doing the task once by hand.
- Keeping it working. When the task changes, the automation must change too. A new biller account number breaks the auto payment until someone updates it.
- Watching it. Someone must read the reports. An alert nobody reads is the same as no check at all.
Automation in a software team
A software team automates many of its own repeating tasks, and each one has the same four parts.
| Task | Trigger | Instructions | Check | Report back |
|---|---|---|---|---|
| Build | Developer pushes code | Compile and package the app | Did it compile? | Build passed or failed |
| Deploy | Build passed | Copy the new version to a server | Is the app up and answering? | Deployment status |
| Backup | Every night | Copy the database to storage | Is the copy complete and readable? | Backup report |
| Monitoring | Every minute | Call the website | Fast enough? Any errors? | Alert to the on-call person |
| Testing | New version deployed | Run the test cases | Does the app behave as expected? | Test report, pass or fail |
The last row is test automation. It is not a separate world. It is the same idea pointed at one job: checking that the software still does what it should. Test Automation Fundamentals zooms in on that row.
Tips
- Automate a messy process and you get a fast messy process. Fix and simplify the manual steps first, then automate them.
- Do it by hand a few times first. You cannot write down steps you have not done yourself. The manual runs show you the exceptions the machine must handle.
- Decide who reads the report before you build. If nobody owns the alert, the check is wasted.
- Count the payback. Time to build plus time to maintain, against time saved per run times the number of runs. A task done weekly for years almost always pays back; a one-off rarely does.