What tools/skillset/process/mindset changes are required to enable progressive/in-sprint automation in the existing team.
Would love to know feedback from people who are following in-sprint automation in your team
2 Likes
Great question, for me it’s always been the maturity of the team and willingness to change.
First off you need to make your team believe that automation in beneficial and will have a Return On Investment. Only then you can suggest to automate within a sprint.
We don’t use any specific tools besides our ticketing system and we create tickets for what needs to be automated also in the newest sprint. We estimate, refine etc just like a regular User Story.
1 Like
Indeed a great question. Support from the team is important, but it also comes down to what you need as a tester. What do you need to do your job? What do you need to keep delivering quality (as a team)? And what do you need as a tester to keep loving your job? Automation helps get rid of endless repeated tasks that nobody likes to do, so why should you? 
We all look for shorter feedback loops and automation helps in that regard. Unit tests are the first level that can get insights in the quality of the product. And they are part of automation. So if your team is already writing unit tests, they are already doing automation Nice entry point.
I belief that automation should be part of your DoD of a regular user story. Automation is part of testing (or checking) that the story does deliver the intended value (and will do so in the future). It is not a goal, but a means to an end. And a User Story is only done when all the work is done, right? So if automation should be in place, why not take it in to your DoD.
3 Likes
Thanks for sharing, Patrick. And welcome to the community. 
Am I right in thinking DoD refers to a “Definition of Done”?
Like how Angie Jones describes it in her talk “Revisited: How to Get Automation Included in Your Definition of Done”?
2 Likes
Thank you. I’m coming out of my lurking in the shadows at MoT
Yes, the Definition of Done indeed. It defines when a user story is “done”, when all the work is completed for that story. That it is a potentially shippable increment I guess.
I haven’t seen the talk of Angie yet, but it most likely will be like that.
2 Likes
Just to clarify, do you agree that “unit testing automation” should be done by the Development team members? To me, QE involvement with automation is developing more end-to-end automation tests or workflow automation… unit testing should be done by Dev.
Just to share, one of the main hurdles I have encountered with including automation as DOD is that in Agile scenarios the stories themselves are too granular and actually represent pieces to the bigger automation puzzle. So my preference has always been to wait for a particular area of functionality to “mature” before bothering with QE automation
4 Likes
Getting test automation done in-sprint is hard, but worthwhile.
In my experience the more prep work you do the easier it becomes. It’s critical to have good early discussions around requirements, NFRs, acceptance criteria, test data, etc. This should start at initial release planning (PI Planning, etc.), then should continue in Sprint refinement/grooming, and sprint planning.
A solid CI/CD pipeline is required. No alternatives. Period.
Within the sprint it’s vital that everyone knows who’s responsible for what level of testing. Hopefully the team is doing Test Driven Development, as that’s crucial for overall success of fast-moving, high quality delivery.
Devs should be writing unit and API tests as part of their regular work, and they should be collaborating with testers on how that’s done. Testers getting involved in API testing can help speed things up too. I’ve also been on teams where testers regularly pair up with devs in TDD cycles–and that’s some of the most awesome collaboration to see.
Functional testing should start right when the work item is started. You don’t need a working system to build functional tests if you know the various endpoints and UI elements–it’s the same approach as writing a unit test in TDD fashion. Build the test, then watch it pass when the full functional slice is completed.
Performance testing may or may not get wrapped into this in-sprint cycle, but at least all the discussion around how and what to test should be accomplished.
All of this isn’t fantasy. It’s totally attainable. It’s hard work to get good at, but it’s a worthwhile effort.
3 Likes