“@maaretp: I repeat myself a lot but remember a mantra: Tester’s don’t break products, just illusions people have about them. #agile2015”
There was a debate yesterday on how much a Scrum Master should know about Automation Testing.
- In favour was a case for how the Scrum Master should have an understanding so they can better promote the best practice between Product Owner and Tester. An extra champion as it were.
- Against was that a Scrum Master is not a ‘task master’ – that she or he doesn’t need to know how Automation works, they just need to facilitate a meeting between the PO and QA. That it’s the QA that should be pushing for time and importance on Automation Testing.
There’s a really interesting read here on an Automation Engineer becoming a Scrum Master, who talks about implementing Automation as part of fostering change in his Scrum Master role.
“I created 2 new automation testing frameworks for my team. I helped the team to start utilizing my automation testing framework using Selenium WebDriver and C#. Furthermore, I am the first individual in the entire corporate to utilize cloud based cross browser testing using an automation testing framework. Finally, working with another colleague, I am helping to add a new test case management tool to our suite. By having power as the ScrumMaster, I believe that I will further excel at fostering positive change in the organization.”
I also have the pleasure of working with a Tester come Scrum Master, who believes that what is good to know is how User Stories should be written – to allow for Automation Testing on all of them.
- “Given That”, “Then”, “When”
For us, automation is something which we time-box for the beginning of the sprint, where our lovely QA doesn’t have User Stories to test. Then each story has an ‘Automation Test’ task on it where the QA deems it needed. Having said that, it’s true that if the Sprint Goal is in jeopardy, or something needs to go – it’s always the Automation first. Because of this it’s important to make sure we’re holding ourselves to ‘Code Complete’ by Friday (2 days before Release/Sprint End).
Scrummastery 