Automation, not always self-evident!

Lots of companies now request automation. And although automation is a good thing, there is a place and time to implement it. When you’re trying to automate an application that’s still prone to have big changes, you’ll find yourself doing a lot of rework. It will make it a lot harder to write tests that only fail when the application is wrong and not the test.

What you can do, is start automating when certain features stop changing. But when they’re not changing, the value of your tests decrease. I believe you should try to find the sweet point.

Stable enough to automate, early enough to have value.

Of course even checks that run in parts of an application that should never change can still be valuable. When one of those fails, something very bad happened! I just feel that this is less likely to happen.

Another problem that rises is that automation takes time and can be complex. So by the time you’re done automating, the feature might be finished and your tests are less valuable then first anticipated.
Also complexity changes over time, so you’ll be automating something that keeps getting more and more complex and your tests never seem to be finished.
When you’re dealing with a tester that’s only just starting out in automation, you’ll find that everything takes even longer and is more complex! Some of testers used to be developers, but lots of tester used to something be else or started out as testers. Automation still requires a default set of ‘good coding practices’ and design patterns.

I’m not very experienced with test automation. This is mainly due to aforementioned issues. I’ve put thought into the issues that I’ve come across and these are the things I’ve come up with that could help.

  • You’ll need experience to find that sweet spot. This is something you’ll actively need to focus on to learn. Discussing this sweet spot and making it a topic can be a good way to find it.
  • Testers can provide end-to-end scenarios that can be automated by developers. They have a better understanding of the code and can implement these tests much faster.
  • Keeping your tests small counters the complexity issue. Sometimes features are just to difficult to be handled by code.


There are many more variable that influence your automation. In this post I only took some of them into account. Please let me know what you think of this, what I missed or should view differently. I’d love to hear a different point of view!

2 thoughts on “Automation, not always self-evident!

  1. “…Lots of testers used to be developers, but lots of tester used to something be else…” Really? Are there loads of developers moving from development, *into* testing? This seems surprising to me, given that the latter tend to be significantly lower income. Or, are you just noticing the bad habit of a lot of bad employers (to move bad developers into testing, because they want to minimize the harm, and because they don’t know what testing is). It would be interesting to see some data on this…


    1. Hey Greg.
      Thank you for replying! I might be wrong, and I certainly don’t have any data. I’ve heard from several people that they used to be dev, but I might be biased in some way.

      Edit: I’ve thought about your comment and had a discussion with my colleague. I’ve changed it to better fit reality. Thanks for changing my view here.

      Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s