Karen Wysopal, Hewlett Packard Co.
The key to a successful adoption of any software development methodology is a clear understanding of the roles and responsibilities of each team member within that framework. As Agile continues its rapid adoption in organizations across the globe, it’s essential to define the role of QA in Scrum as concretely as we’ve defined the other Scrum Team roles.
During our team’s recent Agile transition, I was approached from all corners of the organization, with questions like, “What does QA do every day in the sprint? What are their responsibilities beyond testing and reporting defects? What should they do in the early part of the sprint, when there’s no software to test yet?” Despite being a recent “graduate” of several Agile methodology courses, I found myself ill-equipped to answer these questions. There isn’t much information in the trainings or on the web about the role of QA in the Scrum team. What little I have found is primarily anecdotal, rarely specific, and never comprehensive. While Product Owner and Scrum Master roles are very well defined, QA Engineers fall under the generic label, “Team Member”. We were on our own to define the role of QA in Scrum.
What we quickly learned delighted us: Agile methodology, with its fundamental shift away from waterfall software development, gives QA an opportunity for broader and deeper involvement in the overall software development lifecycle. This enables us better to ensure quality — not by finding and reporting defects — but by preventing the introduction of defects in the first place.
This paper provides a deep dive into the specific, day to day role of QA in Scrum, as our team developed it through the course of our yearlong transition to Agile. You will learn specific responsibilities and activities you can bring to your Scrum teams to transcend the traditional test-and-report, after-the-fact approach to quality assurance. And you will learn to leverage the unique components of Agile to significantly expand your scope of influence, and measurably improve the quality of your software. If you’re not currently working in Agile, you will find these concepts relevant and applicable to other methodologies as well.
