System development has improved significantly with the arrival of agile and DevOps. That often means systems developed in sprints, by multidisciplinary sprint teams, and doing tasks defined as user stories in the sprint backlog.
The roles in a typical sprint team will include development, product ownership, software testing, and automation engineering. There might also be designers, domain experts, and more. In agile, the team as a whole is self-organizing and responsible for the results. A sprint succeeds if the work is “done” at the end of the sprint, and if so, the team will move on to the next sprint.
Testers can work well in sprint teams. The team model encourages cooperation and communication and shares the responsibility for quality.
Generally, a team will include automated testing in their sprint, from low-level unit tests to high-level functional tests, which are often UI-oriented. The importance of comprehensive automation tests is increasing even more as a way to achieve a smooth-running CI/CD pipeline.
However, having to produce comprehensive automated tests within a sprint can be a challenge. The application under test is under construction, and the many changes that can happen in design can derail automation. The testers may not finish the automation by the end of the sprint, while the rest of the team has moved on. And if testers are still working on a previous sprint, it is harder for them to cooperate with the others, losing even more ground.
The team is sprinting, but the testers are left behind.
In order to keep the team together, you need some measures and techniques to ensure that all essential work is accomplished within each sprint—including test automation.
You’re not really done when a key part of the work still had to be finished, are you? When planning and executing work, make automated testing part of the definition of done.
Design both the application under test and the tests themselves to be automation-friendly. For the application, make sure items like element locators are well designed, known early in the lifecycle, and stable. For the test design, a modular and codeless automation approach like action-based testing can help.
Have your technology under control. A separate group or a vendor can help conquer puzzles like how to access third-party controls, deal with graphics, or test a game. A sprint is not the time and place for R&D.
Agree on testing approaches and practices. This agreement is needed within the team, but also between teams and with stakeholders and other outside participants. There is no bandwidth in a sprint to deal with fundamental questions like “How important is testability?”
Also consider outsourcing excess work, either internally or to a service provider. Retain ownership, so the team can stay in control.
To get everyone comfortable with new testing approaches, I have had good experiences with doing a few "sit-down" meetings. Whereas stand-up meetings every morning deal with the work to be done, the sit-down is at the end of the day. Sit back, relax—maybe with a cup of tea—and reflect on how methods and practices are going, and what can be better. Clear communication is the first step to getting everyone on the same page.
