7 rules for (Agile) Test Automation
In a previous project I had to compete against the established experts when trying to introduce a sensible test automation approach.
The reasoning why not to work with suitable tools was mainly based on the fear of change, the unwillingness to automate and the build up idea that when you do automate, the only way to overcome problems is by having expensive licenses.
There are several good reasons why you should automate, but most important is that the team is confident about the quality of the product being developed and gets reliable and fast feedback when making changes.
The specialists on a team should be capable of self-sufficiently building a product and dealing with problems, without having to be dependent on external experts. When working in an agile production environment service level agreements aren’t going to help you, when response times are two to three weeks. Whenever a problem occurs you need to be able to respond immediately, otherwise it will block your entire process flow.
Furthermore agile is all about transparency and collaboration. All skills should be bundled; collaboration is the key to a common level of knowledge and a shared understanding.
Most proprietary tools just don’t embrace the idea of collaboration, licenses are to expensive for tools to be made available to all team-members and often require tool specific programming skills.
When working out these thoughts I came up with the following rules for agile test automation:
- 1. When working in an Agile environment Automation is of vital importance to keep up with the pace of the project, relying on only manual testing is no option.
- 2. Automation must be possible within the multidisciplinary team, no external expertise should be required to create or maintain tests.
- 3. A test tool should be flexible, making it easy to respond to change in terms of environmental, data and technical constrains.
- 4. Creating automated test cases should be relatively simple and intuitive.
- 5. Tests should be readable and understandable (for anybody). Documenting and formatting tests in unambiguous and ubiquitous language supports this.
- 6. Tests should be easy accessible and interchangeable between team-members and preferably also for other stakeholders. Anyone in the team should be capable of adding, viewing and running tests.
- 7. Test execution should be fast and reliable, since fast feedback is your main objective.
Keep in mind that the tool you decide to use is secondary to the process you follow. In the end critical thinking, discipline, commitment and collaboration are the most important drivers behind successful test automation.