Achieving the Goal of In-Sprint Test Automation

Getting test automation done is a challenge, especially within the tight deadlines imposed by Scrum. As much as the thought of continuous in-sprint test automation sounds enticing, the practicality of it may elude most Scrum teams.

Let’s look at some of the main things you need to consider in order to get your test automation done within the confines of your sprint.

Framework

The first thing to focus on is a framework that is useful, is easy to understand, and helps all stakeholders participate in test automation.

This is essential because you want to make test automation a continuous activity that is a part of daily work, not a once-a-sprint (or once-a-release) work item. For this to happen, the framework must make it equally comfortable for a businessperson, developer, functional tester or automation expert to add their contribution and see the results of their efforts.

There are many business-friendly frameworks and techniques, like behavior-driven development (BDD), as well as many tools that can create tests in a domain language and then translate them to script code.

All stakeholders must be trained on using the framework, and their area of contribution must be made clear to them, with practical hand-holding. The automation tester can then focus on maintaining the framework, generating test suites and editing failing scripts, while the creation of test automation will be a continuous task assigned to everyone involved.

Collaboration

The next thing to focus on is collaboration between the various stakeholders. A continuous automation framework can only survive when it is being fed and tended to by everyone on the team.

• The business people, like a business analyst or a product owner, can help by adding user scenarios or defining the requirements in a framework-friendly format. This may require them to be trained on the preferred format based on the framework being used
• The developers can help by creating reusable methods for steps of the script. They can also create and maintain an object repository for all elements they add to the UI while testers use the pseudo names of the elements in the test scripts. This means that the scripts can be created before (and independent of) the application UI, and such scripts won’t need editing when the UI changes, as long as the object repository is kept up to date
• The testers can help by adding more scenarios, specifying and creating test data, and executing the scripts periodically

In this manner, a single script is contributed to by each person on the team, no longer the responsibility of only one automation creator. Again, this can be made possible with a tool or framework that’s easy for everyone to use as part of their daily activities.

Strategy

How to strategize the development of test scripts is crucial to making in-sprint automation a reality. Using API-level automation whenever possible will reduce the time and effort.

Create test stubs for upcoming features that can be filled with actual tests and verifications by the developer when or before they write the code.

And think ahead. When you have a feature upcoming in future sprints, you can begin thinking of its tests now. Use a test-driven development (TDD) approach to think of and develop the necessary framework for its tests now and add the complete assertions later when the feature is delivered.

Completeness

Test automation is an ongoing activity. But a definition of done is still necessary to help keep everyone on the same page. Have clear goals for what and how much to automate for each feature and user story, and for when each can be deemed done.

For example, you can decide that all regression tests for a user story will be automated with different possible test data and executed at least once within the sprint. Alternately, all positive tests for the feature may be automated and added to the regression test pack, to be executed successfully before the end of the sprint and then the reports shared with the entire team.

This makes it easier to quantify and identify what to automate, when and how much to meet the team’s goals within the sprint. A definition of done also clearly indicates when the team has not met their goals, leading to technical debt.

Conclusion

Test automation is a long and strenuous journey. In-sprint continuous automation may be a dream for many teams but taking small steps can help the team move toward that goal.