Tests can be automated. It is not a question of whether it is possible to automatize a test, only whether it is worth doing so. Unit tests and integration tests are automated, and as time advances, more and more tests get automated as we move along to higher steps towards the user acceptance test (UAT). UAT is not likely to be automated. After all, this test checks the integration between the application and the user. While the user, as an external module, can be mocked using automation in lower levels, we should reach the level when the integration test happens without mocks.

There are many tools that help the automation of tests. The blocker for test automation, these days, is the cost of the tools to do so, the cost of learning and developing the tests, and the fear that the automated tests are not discovering some of the errors.

It is true that it is easier to do something wrong with a program than without. This is so true for almost anything not only for testing. And still we do use programs; why else would you read this book? Some of the errors may not be discovered during automated functional testing, which would otherwise have been discovered using manual tests. At the same time, when the same test is executed the hundredth time by the same developer, it is extremely easy to skip an error. An automated test will not ever do that. And most importantly, the cost of the automated test is not 100 times the cost of running it once.

We have used test automation tools in this book. SoapUI is a tool that helps you create tests that can be executed automatically. Other testing tools that are worth looking at are Cucumber, Concordion, Fintnesse, and JBehave. There is a good comparison of tools at https://www.qatestingtools.com/.