In traditional approaches, the QA, Tester, or Quality Assurance tests the work of developers in a separate phase – sometimes months later. Clearly that doesn’t work in an Agile world where delivery happens after every Sprint.
Scrum doesn’t define any traditional roles (like BA, QA, DBA, Dev, UX) inside the team, instead, everyone is a Developer or, better yet, a doer. This lack of strict rules about roles creates stress and tension for people who are used to a traditional approach. They want to know: Who does the testing? When it is done? How to meet strict rules, especially if work is done in regulated industry?
- Most teams have team members with deep testing experience. From a role perspective, a key change from traditional to Scrum is that now they spend part of their time mentoring colleagues to improve quality before a User Story or PBI even moves to testing. (Cross-skilling)
- Teams discover that putting testing last in the process is an invitation to create a bottleneck in test. So, instead, they adopt practices like designing the test cases through QA, BA and Developer collaboration, before work starts on a story and during its development. (Life Cycle of a User Story)
- More advanced teams deepen that collaboration by adopting Behaviour Driven Development and/or Ensemble Programming
Scrum by Example – The Story of an Incomplete Sprint
Resource Links:
- A day in the life of an agile tester
- A Day in the Life of an Agile Tester – Two observations: It is very strange that this group holds Daily Scrum at end of day; This tester is fairly isolated, ideally there would be more collaboration.
- A day in the life of a QA Engineer at Native Instruments
- How Does QA Fit with Scrum? The typical misunderstandings of QA with Scrum
- My Experience as a QA in Scrum
- The Role of Testers in an Agile Environment
