6 Factors to consider to move from N-1 to In-Sprint Automation

Test Automation has changed the software development process in a positive way by providing numerous advantages like faster feedback to the development team, detection of defects in early stages, improving the efficiency of testing and coverage, reducing testing cycle time and overall expenses.

Test methodology has changed in Agile development projects where testing goes along with the development activities so that working product is delivered at end of each sprint. This approach takes a lot of effort for Testers to run all the regression/integration tests in every sprint manually to ensure nothing else is broken with the introduction of new functionality. Having full suite of automated test scripts help the team to speed up the testing and delivering the high quality Product with high confidence.

Many project teams do not automate the new scenarios/functionality in the same sprint, as they would like to have a stable product to play with. N-1 sprint automation ideally works well for such teams.

What if an Agile Project wishes to achieve 360-Degree Automation in the same Sprint at DevOps speed? Sure, this can be achieved with some additional planning and efforts.

Project Team has to plan the following to move towards In-Sprint Automation:

Right Tools: Project Team should have suitable automation framework (for various Platforms/Screens/Browsers) & utilities in place to rapidly achieve Test Automation in the same sprint. Any technology/tool limitation may result in delayed work and carryover of the stories to next sprint. Team should also constantly look for tools/libraries/reusable components to speed up their automation process.

Team Skills: As the project is targeting to have an In-Sprint Automation, it is crucial to have right skilled Automation Engineers for the job, with knowledge of the automation framework and tools. Automation engineers should be multi-skilled – they should be able to define test cases/scenarios, write the code as well as execute the test cases manually.

High Collaboration: Developers and Automation Engineers should be on the same scrum team and have to collaborate closely on the development and Test Automation, as change in functionality will have a good impact on functionality. Testers have to identify the test scenarios in the early sprint so that developers can use those to develop the features. When the whole team works in a cohesion, they can achieve test automation in the same sprint with ease.

User Stories: User Stories should consider Test Automation as well in the Definition of Done so that all activities are taken care along with Test Automation to accept a User Story as Completed. Having this approach helps the team to properly estimate, plan and execute the work towards completion.

Test Cases: Defining the test cases plays a major role when it comes to In-sprint automation. We are expected to write the test cases in a clear, concise, short and feature focused so that, developer can also use those to develop the functionality and tester can use to automate.

Infrastructure: Project should DevOps pipeline configured to Continuously Integrate the work completed by Developers/Testers and also run the Automation scripts to get quick feedback. Having stable and scalable test environments are also crucial for successful execution of Test Automation scripts quickly.

Overall, In-Sprint automation can be achieved with changes in process & skill. As this involves multiple changes in the approach, it may be difficult in the initial phases but team can become proficient gradually.

“We have as many testers as we have developers. And testers spend all their time testing, and developers spend half their time testing. We’re more of a testing, a quality software organization than we’re a software organization.”— Bill Gates

Share your experience and thoughts on this approach...