In this article, I will present 3 principles you should follow to avoid expensive and ineffective test automation.
When software teams want to work agile, it is often a challenge for them to deliver fully functioning software frequently, and the main reason is time consuming manual testing.
As a team coach with experience in agile development practices, I have often seen that it is the manual regression, integration and end-2-end tests that take a long time to execute. As a former developer, I also know that the manual tests can quickly reduce job satisfaction and motivation in the team.
Many managers and software testeres see automation as an obvious opportunity to reduce the time spent on manual testing. Moreover there are countless tools that promise to automate manual tests. However, it can easily end up being an expensive and ineffective portfolio of automated tests.
I will give3 important principles that your test automation strategy should follow.
For automated tests, it is more important to
- Maintain and identify the cause of errors, rather than easily to create new automated test
- Understand what requirement is being tested, rather than being able to execute the tests quickly
- Test automation is implemented within the team, rather than efficient through centralisation
Principle 1:
Maintain and identify the cause of errors, rather than easily to create new automated test
Automation tools focus on making it quick and simple to implement an automated test, with a very gentle learning curve.
It’s a nice criteria, but shouldn’t be the primary focus. Automated tests, like software code, must be easier to maintain than to write. The tests must be easy to read and it must be easy to understand how they are structured, even several years after they have been written. If they fail, it must be quick to locate where the error has occurred and which requirement is being tested.
When there are 10 tests, it is easy to see. But when there are over 500 tests, the value of having a good overview becomes more valuable than being able to quickly add new tests.
The best way to build an automated test is with a three-part test. There are various templates and tools for this, for example Given-When-Then or Arrange-Act-Assert.
If it is not easy to understand what causes a failing automated test, the test is worthless.
It must be easy to identify which area of the system the error may have occurred in. This can be ensured by carrying out the test before the implementation is made (test-driven development) and assessing how telling the description is from the failed test.
Principle 2:
Understand what requirement is being tested rather than being able to execute the tests quickly
When a regression test has to be executed manually, the execution time takes a long time. Therefore, several requirements are often tested with the same test scenario.
For automated testing, the execution speed is significantly faster than with manual testing and the test can also run without supervision. The individual functional requirements can therefore have separate automated tests, without affecting the execution speed.
An example can e.g. be to test that an amount is displayed correctly. The number is shown in red when it is negative and black when it is positive. For automated tests, such a requirement would often be split into 2 separate test groups. A test group where the display is correct for positive and negative numbers, and another group where the number is correctly calculated.
This of course means more tests, so the grouping and naming of the individual tests is therefore extremely important. There are many different ways to name and structure tests. As a team and organisation, you must therefore determine a structure and naming principles that must be followed, in order to more easily search and link tests and requirements.
Principle 3:
Test automation is decentralised out into teams rather than made more efficient through centralisation
The primary reason for executing automated testing is that the individual development teams get quick feedback on whether the system works functionally, they gain confidence in and they understand feedback from the test. When automated testing is created and maintained outside the team, understanding, rapid feedback and confidence in the outcome of the test is lost.
When a test is not constructed in the team, the first response will typically be that it is the test that is wrong and not the system. When knowledge of how the test is implemented and knowledge of how the system works are separated, it is a slow process to find the cause of the error.
The result may be that the test is deleted because it no longer fails or that the result is ignored. With this, trust in the automated tests disappears and the development team does not get any real value from them.
If you want a platform that can be used for test automation by many teams, it can be built up centrally, but the tests themselves must be defined, implemented and integrated in the development by the team themselves.
How to get started
f you follow these 3 principles, you are well on your way to build the foundation for effective test automation that will also give value in the long run. But where do you start? Do you have the necessary professional skills in your teams? Do you have the necessary culture so that your teams are ready to take on the responsibility – and a possible central group ready to delegate it?
There are many obstacles in the beginning, all of which make it difficult to follow these 3 principles. I would recommend that you start as simply as possible. Ensures visible support from the managers and make the individual automated tests visible in the team. Help the software developers get the skills to do automated tests. This can be done, with encouraging the teams do some simple code exercise using Test Driven Development (TDD).
