Lately, I have been thinking about the old discussion about the purpose, pros and cons of automated tests.

There are different opinions when it comes to test automation and I will try to break them down one by one.

Automate everything

Even though this might sound desirable from a test automation engineer standpoint, I am completely against this mindset. The value of exploratory testing in the software development process just cannot be minimized. Apart from it being impossible to create test scenarios to reach 100% application coverage, you would miss out on the human factor. Only thorough exploration of a software under test can uncover complex issues that have multiple nested reproduction steps.

Automate nothing

This is the other extreme. Automating nothing and leaving everything in the hands of the exploratory testers can be a devaluation of this profession. Being faced with the same boring step by step test lists, I have serious doubt that this can be a satisfying everyday work. Plus it actually prevents them from doing what they do best - explore your product.

Automate only the repetitive tasks

This is more like it. If you do something fairly regularly and always follow the same steps while doing it, it should be a potential candidate for automation. This is by no means limited to testing. It applies to all the steps of software creation like deployment and releases, documentation, notifications, monitoring - you name it.

Two common misconceptions of QA and test automation are:

• QA alone is responsible for the quality of a product.
• The more automated tests you have, the less exploratory testing you need.

So what is my preferred approach? It is...

Automate what makes sense

In my opinion, deciding what to automate and in which layer of the test pyramid is a team effort. Developers, Product Owners, QA, DevOps, Release Engineers and whoever else might be part of your software development can be part of this process. Even if you don't do Behavior Driven Development.

Test code should not be treated any differently than application code. That means that automated tests also should go through a similar review and QA process as the main product they are designed to test. Regular refactoring and alignment is key here.

The main thing that I would like to stress is that test automation is not a tool to replace "manual" testing. It is a tool to help with exploration. When a well designed automated test fails, it is merely a signal that your expected outcome is not met. This is not the end - it should rather be considered a trigger to further investigation by skilled testers.