Smooth Sailing: Quality Assurance & Agile

Quality products are our aim, and Agile methodology is our game. Here’s how QA can ensure a smooth journey for the entire project team.

Picture of Rodrigo Alvarado

By Rodrigo Alvarado , QA Specialist

August 28, 2017

Share

In traditional Waterfall methodology, Quality Assurance is geared toward and most heavily involved during the testing phase; so how does QA adapt within an Agile environment? In Agile, all team members are involved throughout all phases of the project. This allows for closer collaboration, earlier issue detection, and quicker problem resolution for the team. It also allows QA to provide input in earlier stages and to ensure the correct process is being followed throughout the project.  

To begin, it's important to understand the difference between Quality Assurance and testing – yep, there’s a difference! When we talk about testing we are simply evaluating the final product without any consideration or involvement in the previous phases. In comparison, QA is when we maintain a certain level quality throughout all stages of a project.

Depending on the project phase, "quality" takes on different forms. In some cases, it's ensuring process is followed; in others, it's supporting development by identifying potential issues or requirement gaps previous to implementation.

Other aspects of QA include:
  1. Ensuring the team adheres to proven processes and guidelines (no funny business here)
  2. Keeping in constant communication with the team to ensure transparency and visibility
  3. Establishing a rapport with the client to build trust and a strong working relationship
  4. Thorough documentation across tracking systems for historical reference, just in case our memory fails us
  5. And, of course, testing

Now that we've covered the basics of QA, it's time to explore where and how QA fits within an Agile project.  Let's dig in!
 

Foundation (Project Discovery)

When a QA specialist is involved early on in a project, they’re able to build a good relationship with the internal team and the client. This allows for more collaboration and transparency throughout the process, which is ideal for everyone involved. Early involvement also means becoming more familiar with the client, the business, and their expectations. Together, we can all become one with the project.
 
3 Men meditate with legs crossed and the ocean in the background

In this initial phase, the team creates the general user story outlines. QA helps shape the acceptance criteria of these user stories by performing a gap analysis on the requirements, so the project can have proper coverage. We define gap analysis as identifying edge cases and flagging any risks (timing, scope, requirement traceability, etc.). This process is then repeated during the planning and sprint phases.

The ultimate goal of Foundation is to create a solid product backlog, so the team can start with the core work.
 

Planning

During planning, project requirements are documented in user stories and refined during backlog grooming sessions. Then, QA can re-evaluate the requirements to identify edge cases and flag any new risks.   

It's extremely important to have the entire team involved in this phase (no member left behind!), as it’s where all requirements are defined before implementation. Once this process is finalized, the product owner will review and approve the completed user stories.
 

Sprints

During the development phase, a subset of the test cases is prepared by QA and all relevant documentation is gathered and reviewed in preparation for testing. When a potential issue arises at any point during this phase, it's advised that development consults with QA. This could be to discuss requirements, any technical limitations found, or to simply ensure the logic is sound. QA is your friend.
Meme of Morpheus from the Matrix movies, what if I told you QA is here to help

By having open team communication, the number of issues found decreases and risks are addressed earlier. And as we all know, the earlier issues are found, the better!  
 
Once sprinting has begun, QA should be well equipped to evaluate the current iteration of the product. Various requirement artifacts will be used to ensure there is proper test coverage. Some of these artifacts include wireframes, creative assets (style-guide, designs, prototypes), user stories, test plans, and technical specifications documents, among others. All the documents!

Once testing starts, the first step is to run a regression test on existing functionality to ensure no new issues were introduced with the new build. Second, all requirement types are verified during this phase: functional, responsive, CMS editing, usability, accessibility, security and permissions, multi-lingual capabilities, etc. If any issues are found, they’re reported and promptly addressed by the team. If a requirement disagreement arises, the entire internal team is consulted until consensus is reached. In order to sail through sprints, teamwork makes the dream work.
 

Client Demo (Sprint Review)

It's expected that before the end of the sprint, QA provides a report to the project team with all relevant information including what was tested, what wasn't working, and which bugs are currently outstanding. During the client demo meeting, QA will support the internal team by clarifying existing issues and keeping track of any preliminary notes or feedback the client might have. By having a demo at the end of each Sprint, the client can be confident that the end product will be the solution that best aligns with their needs.
 

Sprint Retrospective

Sprint retrospectives are the opportune time for course correcting. The team will assess the most recent iteration to discuss which processes were ineffective, which ones actually worked, and then adjust accordingly. When something has gone particularly well, it's essential to identify it and recognize the team members who contributed. This ensures that with each new iteration, processes will be constantly optimized until the team finds their perfect "rhythm."  
 
The success of a retrospective relies entirely on the transparency of the team. If there are issues that were not addressed, it's QA's responsibility to raise the concern as a point of discussion and collectively decide what the best resolution might be. If the team's concerns aren't addressed, they could set themselves up to repeat past issues. The team must learn from history to avoid repeating it. Aye aye, Captain!
 
Photo of various individuals high fiving each other
 

Final Thoughts

It’s clear that collaboration is essential within a project team and that QA, like every other team member, plays a key role in the success of a project. Agile allows for the team to be more flexible and adapt to changing needs as the project progresses. Additionally, by having the client involved at each stage -- from planning to demo -- it minimizes the risk of requirements and actual implementation misaligning. Expertise and teamwork are the keys to success in Agile, so don’t forget to involve QA early and throughout the project to ensure a smooth ride to the finish.
 
GIF of men rowing in tranquil water