Adopting agile into your organization requires education, commitment, and adjusting software development structures and practices. Teams struggle at first to settle on the right implementation for their organization. Since part of the agile methodology message is an increased gain in quality, they ponder if they now need the role of QA in this process. The short answer is yes: the primary role of QA in agile is to prevent bugs, not find them.
If agile gives me quality software by default, why do I need QA resources as part of the agile process?
The data does indeed show that agile improves the quality of software being delivered. But quality does not stop there and since when does some quality improvement represent the final goal? Agile iterative design, developer ownership in testing, and client acceptance all do produce much improved software deliverables, but QA has a key role to play if you intend to be successful.
What Is Software QA?
Many definitions exist but Webopedia defines it as, “a level of confidence that software is free from vulnerabilities, either intentionally designed into the software or inserted at anytime during its lifecycle, and that the software functions in the intended manner.”
Traditional Role of QA in Water Fall Development Process
If you’ve been in software development for any length of time, you likely know the traditional role of QA. Architects and developers go off and design a software feature and create a design artifact they hand over to QA to read. While developers are writing code, QA reads the design document, and designs a testing plan based on expected features and identifies areas of vulnerability. Near the end of development cycle, QA receives a build and begins their testing plan. Usually a lot of easy bugs are identified early on. Development continues to fix bugs and deliver builds but eventually, as the effort nears the end, the identified bugs get more severe and time is running out. Finally, the dreaded issue severity negotiations begin.
Expected Role of QA in Agile
The traditional paradigm morphs with agile.
QA is now ‘part of the team’ and not an outsourced black box of activity. They are in all the planning meetings from day one and every day after. During planning, QA will have a great deal of input and raise helpful questions developers may not have thought about. This will result in refined implementations. Stories will be scoped and planned with the expectation that early and frequent drops are available to QA, hopefully using continuous development practices. Stories are planned and committed to as a team, so the QA time effort estimate is part of the overall story point assignment. It is an easy mistake to discount QA time as part of the story estimate—don’t!
With agile, developers now have a clear mandate to be part of the quality process. Developers perform unit and integration testing and a testing coverage rate is usually outlined. QA owns the system testing and of course still performs functional testing. They ensure regressions are discovered and force a greater degree of ‘doneness’ on the stories.
Follow the Nike Slogan, “Just Do It”
Assign QA resources to your new or existing teams and begin the sprint. Make sure they are part of the story point assignment.
Remember, it is a learning process. Is it right the first time? Doubtful. But the next time will be better and so will the one after that.
Make the Assignments
Assigning QA to scrum teams would follow the same guidelines as the initial team formation. Basically, making assignments to teams should be based on technical expertise in relationship to that team’s technical objective. If everyone is new or resources are limited, so be it. Story point commitment should reflect this.
QA to Developer Ratios?
The classic saying ‘it depends’ applies here. I’ve seen many articles that discuss experiences ranging from one QA to 10 developers and even in some with a one to one ratio. My experiences have been around one QA to four or five developers and that has generally served our need for very complex projects.
What Meetings to Include Them In?
They are part of the team so include them in all scrum meetings including grooming, kickoff, planning, sprint review, retrospectives, etc.
Can QA Resources Cross Scrum Boundaries?
In an ideal world, they are dedicated to one team. But in my experience where we operated with three parallel scrums on the same product development cycle, it was not unusual to utilize the same QA staff across a couple of teams if needed as long as the planning sessions accounted for this when committing to stories.
What Can I Expect to See After a Few Sprints?
Overall, agile testimonials and my own personal experiences show that quality does go up. And therefore, business value to end customer goes up with each sprint. The primary role of QA in agile is to prevent bugs, not find them. In addition to the expected successes I’ve listed below, there will periodic story completion impact as well, which would prevent stories from reaching the successful acceptance and done criteria as planned. With QA comes increased quality and higher standards. After all, you have invested in QA capital to ensure your product is high value, right?
Challenges still exist even as we make improvements.
Now that QA is part of the scrum team, will the testing exceed the acceptance criteria agreement?
– QA will have a tendency to work within the boundaries that all agreed to during planning. Quality starts at the beginning and well-defined acceptance is key for product owners to either accept or reject the story
Will late issue discovery still occur thus having the potential to block story acceptance?
Sure, no magic pill here. Issues are still discovered, not just prevented. The team (and ultimately the product owner) will have to decide the impact to the client to know the effect to the story
Expected Successes
– High-risk areas identified which are critical to the business: Vulnerable failure points identified and tested thoroughly.
– Higher quality resulting from daily involvement: QA gives early feedback on features as they are developed throughout the sprint. No more tossing features over the wall.
– Better estimations due to early design input: QA provides real test estimates, which improves overall story estimates.
– Well-defined acceptance criteria: It is in everyone’s best interests to spell out when a feature is complete, putting the cap on scope creep testing.
– Higher test coverage: You can use tools to rollup the complete test coverage percentage by combining unit, integration, and system tests.
Fewer regressions: Result of automation regression testing if applicable
Conclusion
Over the years, I’ve worked closely with QA organizations as we developed and rolled out continuous software releases. They all had dedicated and talented QA whose desire was to help ensure a quality software product. But there was always a bit of an antagonistic division between the two separate groups even though we were working toward a single goal. Agile teams that incorporate QA remove some of that natural division by the very nature of team story ownership, enabling the team to work closely together to deliver software with the highest quality and business value possible.
Exclusion of QA from scrum team membership would only be practical in very special environments where a team is fully tasked with R&D of some sort, which is therefore not organized to deliver client business value in each sprint.
Contact Us
Ready to achieve your vision? We're here to help.
We'd love to start a conversation. Fill out the form and we'll connect you with the right person.
Searching for a new career?
View job openings
