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.
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.
I was always thinking that the feature might not be stable enough(changing requirements) to do in sprint automation but your article really changed my perspective. I just had few questions on the timeline of your sprints and how do you achieve the feedback loop of acceptance criteria review, 3 amigo discussion and complete automation test successfully in a sprint. Thats where I am facing challenges in my current org. If you could advise me on the timelines and how you achieve this it ll be a great help
When this term In-Sprint Test Automation is said by a stakeholder or a initiator in the company then we should be very cautious about taking it in agile practice of sprint.
By hearing this term and directly implementing within team may impact non-empathy driven culture with in team and company.
Steps -
Do research about In Sprint Test Automation.
Do research and understand practicality of the word empathy with in team or company.
Check hows bond between Dev-Ops : Dev : Tester.
If all goes well and the three mentioned in previous step are ready to support each other in tightly coupled mindset then start the practice.
Manager or the Stakeholders should understand the technical and non technical challenges which are happening with the core level contributors and should zoom in to reduce friction.
Empathy, Hardwork, Understanding Challenges can do wonders in a bad situation.
Good day @sarahdeery ,
In-Sprint Test Automation: Making Agile Dream Come True
Without mincing words, we are going to be blunt with in-sprint test automation. It is actually not a unicorn to chase. It is applicable, practical, and doable way of changing the automation approach for Agile teams.
The myth and the factuality
For years, teams have been grappling with the seemingly impossible charge to automate tests while they kept pace with rapid development cycles. Most have surrendered toward an unending game of catch-up, where testing always seems like an afterthought and is not integral to but a part of the development process.
But the fact is, in-sprint test automation is NOT only possible, it is a potential revolution.
Bursting the Bust
The secret lies not in some magic toolset or superhuman testing capabilities. It sins under a fundamental shift in the way we have all worshipped testing in Agile environments. We are talking about:
A paradigm shift: Testing as an ongoing collaborating effort instead of just a discrete phase past development. Developers and testers together, not bottlenecked.
Tool Mastery: Become intimate with your automation tools. I mean really intimate, so you can know how to use automation to work smart, not hard.
Open-Mindedness: Going with the storm of Agile development but keeping a rigorous ballpark of quality standards. It is part science, part art, and 100% commitment.
Real-life Realization
On the basis of experience, in-sprint test automation is about progress, not perfection. There will be falls, a few unplanned hiccups, and a moment or two when you will feel like throwing your laptop out of the window. Those are the moments that define expertise.
In the section " Educating My Team On Solid Practice" - do you mean, as in SOLID principles or something else like good practice etc.? @swathika.visagn
