Automated acceptance tests: where to start?

The idea of this post is to share an important tip when talking about writing automated acceptance tests.

While reading a chapter from the Continuous Delivery book (by Jez Humble and David Farley), about implementing a testing strategy, there was a sub-chapter about business facing testing techniques that support the software development process.

In the book, the authors refer to the testing quadrants, at first mentioned by Brian Marick, where there are testing activities from the business and technology perspectives, and there are activities that support and critique the project.

The automated acceptance tests are in the business facing and project support quadrant, as already mentioned. This is the square of this post.

When talking about automated acceptance tests in this context, we can think of different test scenarios: the happy path scenarios and the alternate paths.

The happy paths are basically those who exercise the application to successful complete a transaction, such as a successful login, completing a purchase in a e-commerce system, or the creation of a new account into the system.

The alternate paths are those who exercise the application for the cases where the user, for example, is not able to complete some action, such as trying to log in with an invalid user and/or password, a purchase tentative with a stolen credit card, a form submission without filling some or all the mandatory fields, etc.

Now that we already have some fundamentals, here is the tip about from where to start, when starting writing automated acceptance tests. Start by the happy path scenarios! =D

I say that based on what is proposed in the book, because by creating this kind of tests, you can guarantee that the main application functionalities are working after changes, such as: adding new features, bug fixing or refactorings. The important thing is at least to ensure that the end user will be able to follow the happy path without any issue. Without test coverage for a successful purchase on a e-commerce system, for example, it would result in financial lost. Think about it!

As an extra tip, happy paths automated acceptance tests can be used for the creation of a smoke test suite, for quick feedback after application changes, ensuring that the most important is ok, and then the regression test suite can be executed in a different moment of the continuous integration pipeline since such tests have high cost in time of execution when compared with the smoke test suite. And if after some change the smoke test fails, there is no need to waste time running all the regression test suite.

After a good base of happy path tests, then you can start thinking on the alternate test scenarios.

I hope that this article can be helpful and I’d love to hear 👂 about your experiences with automated test.