A day in the life of an automated tester

What does an automation engineer do?

What skills does he need?

How does a work day look like?

What problems does he face?

How are they solved?

What else except writing code is involved in test automation?

Are all automation jobs the same?




Test automation jobs are as diverse as the manual testing ones.

Many things can be different between 2 automation jobs:
  • application type: web site, mobile app, windows application or a console utility
  • programming language: automation is done mostly in Java and C# but also in Ruby, Python and JavaScript
  • automation library: open source (example: Selenium WebDriver, Appium, Robot Framework) or proprietary (UFT)
  • how the tests are designed: unit tests, behaviour integration tests, etc
  • project's design: page object model, page factory, keyword driven are just a few different models that can be used for automation


Test automation jobs can focus on different things.
Some create the automation project from scratch.
Others create tests for an existing framework or redesign existing automation frameworks.


Every job is about solving problems.

This series of articles aims to describe a day in the life of an automated tester, the problems that the tester has and their solutions.

Everything that follows is about a fictive job but inspired from reality.

Thanks for reading.



Day 4 - Page Object Model
Day 3 - About Automation Test Data
Day 2 - What Type Of Automation Job Is This?
Day 1 - First Day Of A New Job

The good, the bad and the ugly of test automation

Each manual tester that I know wants more excitement and challenge in his day-to-day work.

Because, lets admit it, manual testing gets boring at times.

So the testers look at the next best thing such as test automation.

They imagine a day when, having enough knowledge and skill, the manual testing will be traded with test automation.

Which will be exciting, challenging, interesting and never boring.

In other words, Good.

This is obviously not true all the time.

Test automation experiences can be good.

But also bad.

Or ugly.

Good, bad and ugly, 3 faces of test automation.



Have you seen this movie with Clint Eastwood?

The good, the bad and the ugly is one of the greatest films of all time.



It is about 3 gun fighters, the good, the bad and the ugly, all in search of a burried treasure.

Clint Eastwood as Blondie: The Good, a subdued, confident bounty hunter, capable of pity and providing comfort for dying soldiers,

Lee Van Cleef as Angel Eyes: The Bad, a ruthless, unfeeling, and sociopathic mercenary.

Eli Wallach as Tuco: The Ugly, a comical and oafish but cagey and resilient, fast-talking Mexican bandit who is wanted by the authorities for a long list of crimes.



Back to test automation.

How are automation projects good, bad or ugly?







The Good

You get hired to create test automation scripts for a web site.

The website already exists and it is stable.

There is no test automation in place.

Test data is easy to get and recreate.

The test environment is not shared with other test and development teams and can be easily refreshed.

It is your responsibility to create the test automation project from scratch including
  • the test scripts
  • the page objects
  • the test automation framework

You have the knowledge and the skills for the job.

You will not do all work by yourself but as part of a team that includes other people with similar knowledge, motivation and skills.




The Ugly

You start a new job and get handed an automation project created a few years ago.

Multiple teams worked on it during this time and created a few thousands of tests.

The tests run with a 30% fail/error rate.

The code has
  • tons of duplication
  • classes with thousands of lines of code
  • lots of static delays and implicit waits
  • it supports multiple applications (mobile site, desktop site)

The page object model is applied incorrectly with each page class having separate methods for clicking, typing, getting the value of each element.

The test environment is shared with other manual test teams.

The test data is very difficult to configure and recreate.

It is your responsibility to clean the project up, to stabilize it by reducing the fail/error rate and to bring the project in shape.








The Bad

This is when you get hired for a test automation job and you are not ready for it.

Your skills are incomplete and your experience limited.

There are high expectations from you and you cannot deliver.

Not without significant time dedicated to training.


3 faces of the same experience.

The good, the bad and the ugly of test automation.