If the company or client you’re working for has (like so many other IT departments) transitioned to or is already using Agile, what can QA expect? To begin the discussion about what the role of QA is in Agile, we should first discuss the different roles in most Agile methodologies like XP and Scrum.

In Agile, there are 3 recognized roles: Scrum Master, Product Owner, and the Development Team.

• The Scrum Master is a servant leader who guides the team, communicates with Stakeholders, clears roadblocks, is a process mentor, and acts as the facilitator.
• The Product Owner’s job is to bring the customer to the table by setting the vision for the Product, creating and managing the priorities for the product backlog, and being the ultimate business decision maker.
• The Development Team is a self-organized, cross-functional team whose sole purpose is to get the work “done”. We must immediately note that there is NO standardized or proscribed make-up within the Development Team. It is this fact that leads some within the IT community to believe that formal QA isn’t necessarily needed within an Agile team as the work can be accomplished by other roles. However, most Development Teams within Agile will consist of architects, BAs, developers, and QA analysts.

Now that we’ve discussed the roles within Agile, let’s review some of the major tenets/principles of Agile and examine their impacts on the role of QA. In the past, traditional QA relied heavily on three things: process, documentation, and tools. With these three things and involvement upfront, QA departments could largely comprehensively test a product to make sure it conformed to requirements prior to release. In Agile, these three things take on much less importance as Agile favors individuals and interactions to process and tools and working software over comprehensive documentation. That is not to say that Agile does away with these three things but because Agile focuses on responding to change over following a plan, process, documentation, and tools have to be flexible in order to make Agile lean and efficient. Ultimately, that means process, documentation, and tools get incorporated when needed, not locked in ahead of time. Changing the focal point of QA within Agile forces seasoned QA analysts to psychologically change their approach to QA from a process and documentation driven approach to a much more collaborative and delivery driven model

Let’s discuss how QA employs the collaborative and delivery driven model within the responsibilities they inherit as part of an Agile team. Let’s discuss QA’s role in the 4 Agile meetings: Sprint Planning, Daily Stand-up, Sprint Review, and the Sprint Retrospective.

In Sprint Planning, QA helps determine the Sprint scope by working to establish acceptance criteria for User Stories, estimating the level of complexity within each User Story, and detailing a preliminary set of tasks for each User Story. During the Daily Stand-up, QA discusses what got accomplished in the previous day, what will be the focus of work today, and if they have any obstacles that need to be removed.

The Daily Stand-up is the pulse of the Sprint where the team communicates progress and QA plays an important role because they can define when Stories are “done done” which has a direct impact on the team’s burn-down.

QA also plays a large role in a Sprint Review. Typically, QA will lead the demo within the Sprint Review and will show off the functional delivery for the Sprint. It is important that QA shows their total understanding of each story as they demo the product as it sends a clear message to the stakeholders that IT is working with them.

In traditional SDLCs, post-mortems were the domain of the QA teams. QA teams were focused on process and analyzed what worked, what did not work, and made recommendations on how to fix it. In Agile, this review is the responsibility of the team in the Sprint Retrospective. This meeting should be where QA shines as reviewing process is an activity that QA is engaged in all the time.

Now let’s focus on what day-to-day responsibilities look like for the QA team within an Agile environment. Most QA activities within Agile are NOT different from other methodologies. Agile QA teams still analyze requirements (user stories and acceptance criteria), create test cases, execute test cases, engage in the defect resolution process, and look for automation integration. The difference in Agile QA comes in how these activities take place. When working on day-to-day tasks, QA teams do not sit in isolation; they are collocated and collaboratively work with the Development Team to complete tasks as efficiently as possible. For example, when the QA team identifies an issue, their responsibility is to gather all the necessary details and log them into the issue tracking system but their responsibility also extends to having an immediate conversation with both the BAs and developers to assess the issue. In most cases, a resolution for the issue is determined within the conversation and the entire team is made aware of the ramifications of the change. Everything that the QA team does within Agile is predicated on the concept of the immediate feedback loop.

Since everything the QA team does within Agile is predicated on the concept of the immediate feedback loop, where does that leave the need for QA metrics? In more traditional SDLCs, the QA team is responsible for regularly providing comprehensive status reports full of metrics. However, in Agile where one of the central tenets is working software over comprehensive documentation, the QA team is not as obligated to provide regular, exhaustive status reports and metrics. The Scrum Master is responsible for providing the team with a Sprint burn-down chart and a Project burn-up chart which serve as the key information radiators for the project’s overall health. If comprehensive status reports are requested of the QA team, seek out the Scrum Master and have an open dialogue about what value the report has and whether or not that value supersedes completing the Sprint work. In most cases, reports will not serve to provide any better details then what is already being provided and if the reports are necessary, the work to create them may fall on the Scrum Master more than the QA team.

To summarize, much of what QA teams do in Agile is not significantly different from more traditional methodologies; the difference lies within how the QA teams accomplish their responsibilities.

• First, QA teams need to be focused on lean, flexible process, tools, and documentation which comes in stark contrast to traditional QA methodologies.
• Secondly, QA teams need to be focused on a collaboratively working environment, one focused on trust and doing things for the betterment of the team.
• Finally, QA teams need to embrace the idea that getting tasks completed as quickly as possible dictates that they ask themselves what value each work task provides. If a task holds little value or does not move the team forward, work with the Scrum Master and the team to decide whether or not the task can be eliminated.

Ultimately, being a productive Agile QA team member requires a little retraining on what is most important to the project: quickly having a quality releasable product.