When we are working on software delivery projects, we will eventually face the decision of whether or not we should automate a test for a specific scenario. The question of whether we should automate or not, is what we will discuss in this article.
Why we Automate
Generally, we automate to avoid repeated manual work, get faster feedback, save time on running tests over and over again, and ensure we are always executing tests consistently with the same preconditions and expectations.
Repeated manual tests are boring. Also, humans executing a bunch of tests manually, doesn't provide the same result each time. Factors such as confirmation bias and human error come into play. At some point, a person could execute a test manually and miss an important step, thereby failing to identify a bug in the application being tested.
Fast feedback is important for any successful continuous integration strategy, and critical as you move towards Continuous Delivery. It allows you to identify if there is any regression in the quality at the time the code is committed, allowing the team to fix problems as soon as they are introduced. Fast feedback also allows us to have our test scenarios reproducible at any time we need to run them again. The team will also rely on it in order to implement changes, or to re-factor the code.
But, even with all of these as benefits, it doesn't kill the need to have exploratory tests in the application at some point in the pipeline.
What we Automate
When deciding what tests to automate, firstly we need to look to Mike Cohn’s Test Pyramid. In essence, the pyramid prescribes that there are many more unit tests than higher level integration, service or UI automated tests.
The natural instinct of someone who is new to test automation is to attempt to cover every single scenario that they would test manually. Continuous integration requires automated tests, because for every small change, we are able to re-execute all regressions and make sure we aren't breaking anything.
However, functional tests can unintentionally create a huge set of test cases, thereby generating inconvenient consequences. Even if for each new story we add a small set of functional tests after some iterations, our regression suite will take considerable time to run. A long running regression test suite quickly becomes a bottleneck when committing changes. As a consequence, developers will commit less frequently, with larger commits.
As an application evolves, we don’t simply want to maintain an ever growing set of test cases that are passing forever. We want a test set that guarantees that the new and existing features are working as expected. A more efficient approach would be to cover the areas which are more important from a business perspective, or are known to be unstable and have a higher probability to introduce defects.
Our focus should be to create a high value test suite, which focuses on the business critical areas of our product. To achieve our goal, we need to take both views into account by associating two concepts with each story: business relevance and rate of error of each feature. This way, we can build a matrix to determine which features have more impact and should have more tests.
For example:
| Features | Business Relevance | Error Rate | Total |
| Inbox | 2 | 3 | 5 |
| New mail | 1 | 2 | 3 |
| Login | 3 | 1 | 4 |
| Settings | 1 | 1 | 2 |
As we know, the business relevance changes over time and the probability of failure in a test, that is passing for a long time, is low. Test results should be reviewed constantly to determine which should remain in our functional test set. So, we suggest that you evaluate your tests at every iteration.
Conclusion
When implementing continuous integration, it is important to have a suite of automated tests that executes quickly and provides confidence in your product. Being able to deliver business value quicker than your competitors is becoming very important in a digital marketplace. A good test automation strategy that can ensure quality software faster, puts you a step ahead of your competitors. But, we know that there is no silver bullet when we talk about test strategy. It will always depend on the project and the kind of tests we need to focus on, to achieve the project goals.
