Quality Assurance in Scrum

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