Doing so has several drawbacks:
- The team has moved on and is already working on other features which leads to
- less motivation
- less support
- less knowhow
when it comes to create test automation for features of the previous sprint
- No development with test automation in mind: the test automation is decoupled from the actual development process so developers do not care much. Therefore it can happen that the feature implemented cannot be tested efficiently and the developer already has a different feature to implement so doesn't have time to fix it.
- Automation will suffer because of more current tasks - since the feature was part of the previous Sprint backlog, there are for sure more important tasks in the current sprint than creating test automation for features of past sprints. This gets even worse if automation can't keep up with the development speed.
- Story is not done - A story can be considered done if also testing is done. This is only the case if automation has been created and is stable. If not, the story is half done and shouldn't be closed or released. If the story still gets released it weakens the importance of test automation.
- Automation only for regression, not for progression testing: If the test automation is done right, it can also be used for progression testing in the current sprint. By automating the most common paths (happy path, ...) for a feature, testing it can already be done using automation. This is especially useful if other parts of the feature (like error and exception handling) are still under development and might have impact on the common paths.
Why creating test automation for the current sprint works
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:
- Develop with testing in mind
- Use stable IDs in the UI
- Stabilize interfaces early on
- Integrate automation into delivery pipeline early on
- Automation is a part of the definition of done and no feature gets deployed without sufficient test automation
The advantages are obvious:
- Testing is part of the Sprint, Developers need to care about it
- Due to the timing, Sprints get less overbooked and the quality of development increases
- Test automation is always up-to-date
- The velocity of a team will become stable - no slow downs because of technical debt
- Everyone will help to finish test automation because otherwise the feature will not be done and not released