Next14 Dec 2018, 15:14
Often functional test automation (UI test automation, REST test automation) gets created in the next sprint after the feature has been completed and sometimes even released to production. The reason for this is that the many think a feature needs to be fully implemented before test automation is created. Another reason is that there is not enough time in the current sprint and creating automation is therefore pushed to the next one.
Doing so has several drawbacks:
Usually, the development of a feature starts with implementing the happy path. So the developer tries to provide the necessary functionality as soon as possible, without much error and exception handling). This usually takes 20 to 30% of the total time necessary to finish the implementation of a feature. Same thing is true for interfaces, batches and all other implementations. Once the happy path is ready, the test automation can be created. So there is more than enough time to create the automation in the current sprint. The next chart visualizes the timeline of a Sprint regarding feature development:
The chart shows the link between feature development and feature testing. While the happy path is implemented, testers can start with test preparation (e.g. preparing test env, test data, test case). Once the happy path is ready and has been deployed to Acceptance, testers can start with test automation. The developer needs to continue with error handling and special cases. Only parts of these cases should be automated and this can usually be done very fast based on the happy path test automation. Once the feature implementation is finished, the automation should be done as well and testers can start to focus exploratory testing.
If the sprint is timed right and everything is in place, this approach should work well. Here are some best practices to make it happen:
The advantages are obvious:
About the author:
Chief Solution Architect / Delivery Manager
In his role as CSA, Walter is responsible for designing and implementing fitting solutions for well-known enterprise companies. As a huge fan of Continuous Improvement, Walter is currently focusing his research on DevOps, CI/CD and agile methods.