Can In-Sprint Test Automation Really Work for Agile Teams?

Our latest article by @swathika.visagn, “In-Sprint Test Automation On Agile Teams: Yes You Can!” unpacks the feasibility and benefits of integrating test automation directly into your Agile sprint cycles.

Swathika breaks it down with real talk from their own experiences, showing that getting into in-sprint test automation isn’t some unattainable dream—it’s totally doable with the right approach and mindset.

The article is packed with advice on how to make it happen, like getting familiar with your automation tools and how to keep up with your team’s development pace by testing on the fly. Swathika doesn’t just advocate for in-sprint automation; she provides a roadmap with successes, challenges, and the occasional humorous mishap.

After you give it a read, we’d love to hear your thoughts. Swathika shares various methodologies and mindsets for successfully integrating testing within sprints. Which strategies have you tried or are you planning to implement in your team? Do you have additional tips or a success story to share on navigating in-sprint test automation?


When a user story in the backlog is added to the current sprint or iteration, developers and testers work on the user story in parallel. So it’s good practice to have dev and QA tasks added to the same user story.

This is what I advocate for in my blog article and practice it my self.
Risks, priorities, test coverage, etc. can be discussed before any code is written (or in parallel).

Some simplified variants of when what work is/can done.

The only real dependency is having a executable to interact with.
And even here you not necessarily need to wait for the story to be full developed. You can start interacting with the executable with just a few lines of code changed. Just discuss with the developer what your focus should be for the moment.

I also use Responsible and Supportive Testers from James Bach.
As a single tester in a Scrum team I often guide my developer coworkers in their testing.

All of this applies for me for automation as well for any other testing task.

Edit: added more details.


I’m confused as to why you would not do automation “in-sprint” and automate alongside code delivery in the same sprint-board. I worry every time someone makes it sound like fresh news that we should all be doing a thing. Because a lot of us are doing this already anyway I’ll bet.
BUT we are not doing it with the MINDSET of testing in-sprint, we are testing in-sprint because left-shift tells us we really need to. And so I like the fresh approach by @swathika.visagn . I’d love it if more people could use their entire team (I have a team of 3 and I still do this badly) and introspect and evaluate what and why they are trying hard to test early. To take the good bits, and water and tend them well. Bravo.