In our first blog of the 3 series "First Aid for Testing in an Agile Environment" we discussed the importance of an all round tester and the "baggage" this tester needs to make agile work a success. In doing so, we in blog 2 we talked about the fact that everyone involved in testing needs to commit to the testing process. A clear test strategy, communicated to management, is essential. In this last blog of the 3 series "First aid for testing in Agile environment" we will focus on test automation. We are talking about test automation of both the test process and the execution. The possibilities for test automation are becoming more and more mature. How do you apply these within an Agile environment, in such a way that speed and maintainability are guaranteed?
Test automation can be applied to several areas: the automation of the test process and the automated execution of the test scripts. Ideally, these overlap. They will therefore be discussed in this blog.
In an automated testing process, the design of test scripts and their execution is recorded in a testing tool, such as HP Quality Center or Testersuite. It should be made clear in advance which tests will be performed manually and which tests will be automated. Subsequently, the results of the execution must be recorded in the test tool. Also if there are developments within a certain test script, this will have to be updated in the tool. A major advantage of the test management tool Testersuite is the fact that existing test scripts can easily be reused. Testersuite contains a regression test set that is very accessible so relevant test scripts can be found quickly for reuse. Especially in a complex landscape, testers cannot do without a test management tool. It is otherwise difficult, if not impossible, to maintain an overview. It becomes even more difficult when working Agile with multiple scrum teams. In that case, many changes are implemented within the systems in a short period of time. Using a good test management tool, the Scrum teams can keep track of what has been tested, what the results were and report on them.
When we talk about automating test execution, other test tools come into the picture. These used to be tools that were mainly used by programmers. Now there are various tools that a functional tester can also use well. Nowadays you can use these tools to automate the test scripts yourself and provide them with the correct test data. This allows the test scripts to be used more often and more efficiently. The tester within the scrum team can also take care of the automated execution of the regression test, among other things. A major advantage of this is that it becomes clear early on in the development process whether a change will have an impact on the unchanged systems. And that is something you can never achieve with a manual implementation, or only at great expense.
However, it is essential to use the right sequence in test automation. Many companies are very happy with the test tool, where the focus is mainly on the automated execution. With that, hardly any attention is paid to the design and the way of maintaining what has been automated. That is why it is wise to first think about a good test process, which clearly describes what is being tested, why (risk) and how. This test process must be clear to all scrum teams and they must demonstrably embed it in their scrum process. Only in this way will changes be properly tested and the test scripts adapted for future implementation.
A clear test process is therefore essential. If this test process is in place, one can proceed to realise automated execution of the test scripts. And also in this case, structure is a major point of attention. Firstly, make sure that the chains are chopped up into testable chunks and shape the test objects in such a way that they can be reused in multiple scripts. This prevents you from having to adapt many scripts in the event of a change. There is already a lot of expertise in this area in the market. The central question is therefore:
"How to choose the right subdivision and objects and how to identify them so that they can be easily found after an adjustment in the systems".
Apply this expertise within the test automation and ensure that it is robust, i.e. that it moves with the changes in the systems. This robustness is necessary within an Agile environment. Especially within companies working towards Devops, where adjustments in the systems are immediately transported to production after acceptance. At that point, it is necessary to find out within a short period of time how much influence the change has on the parts of the system that have not been changed. Which test scripts have been executed? And to what extent do they have the desired test coverage? This is where the testing process comes in again. And if there is experience with the automated execution of the regression test, then the automated execution of the unit and acceptance test is also open. Whereby the scripts run from one type of test to the other. For this, an all-round tester is no luxury. He or she ensures that the test types and the scripts support each other and prevents duplicate testing.
This was the last tip of the blog series "First Aid for Testing in Agile Environment". Testing in an agile environment therefore requires robust test automation, from a committed test process and supported by all-round testers!