Automation beyond the Selenium script

Room 4

In 1948. Delmar S. Harder, vice president of Ford Motor Company, coined the term “automation”, referring to the movement of automotive parts from one machine to another in the manufacturing process. From 1948 until now, our obsession with automation was escalating, in our wish to lower the amount of human work and to increase productivity.

In the context of agile software development, the first thing on our mind when we hear the word “automation” is actually “test automation”, or at least very limited perception of what that really is. When Ford engineers automated their manufacturing process, the idea was not to “automate something” in their process. Instead, it was the other way around: they recognized the repeatable, automatable part of the process, where automation could provide huge value to their work.

Following this model, let’s take a step back from our perception of automation in software development, let’s take a fresh look on how our daily work looks like, and reconsider our ideas on what, when and why we should automate.

Key Takeaways

  • What test automation really is
  • What else could be automated
  • How to recognize the automatable
Automation Track