Who is Responsible for Software Quality in Agile?
The QA process in agile differs greatly from QA in traditional testing, such as in Waterfall. Agile has changed the way we think of software quality. In fact, I have read rumblings in the blogosphere that Agile has killed QA. I promise you Quality Assurance is alive and well on agile teams. It just looks different than what most of us are used to. I think people who have promoted the “death” of QA in agile are not looking closely enough at what is really happening. Traditionally, testing was the only task people associated with measuring quality. Also, testing was only done by the tester, and wasn’t associated with other members of the team. In the World Quality Report for 2019/2020¹, 41% of respondents said there is a lack of a good testing approach that fits with agile development methods, but I’m not sure I agree completely with that assessment. First, testing is not the only measure of quality, so when we are looking at the World “Quality” Report, we have to be cognizant of that. Second, I’m afraid that many respondents are viewing testing approaches through the lens of traditional (waterfall) projects instead of embracing the behaviors of successful agile teams to understand what quality is and who is responsible for it.
QA Process in Traditional Testing
In waterfall projects we typically had a tester or two on each team who would eventually get the requirements document, digest it and write test cases. Then, when the code was finally ready and stable enough to deploy to the test environment, the tester(s) would jump in and feverishly execute a huge amount of test cases, stopping only to write defects. There was a Business Analyst that wrote the requirements, followed by a Developer who wrote code to those requirements, and finally (and usually far past the original schedule) the tester was last in line to “QA” the code. There are two major issues with this approach. First, each step of the project lifecycle belonged to someone in a different silo: Business, Development and then QA. Second, by the time the code made it to “QA” there was no hope of building a higher quality product. The quality was either present or it wasn’t and all “QA” could do at that point is find out how bad the quality was. Hint – it was rarely good, otherwise agile adoption would not be as big as it today!
In these instances, the tester was the face of quality. The last piece of any waterfall project was the tester slogging through their test cases, trying to get them all executed in a shorter period of time than expected, usually because dates for the other phases of the software development lifecycle had slipped. For these projects it was common that the tester wasn’t usually a contributing part of the team until much later in the project. They weren’t at Project Kick-Off meetings or at Requirement Reviews or Design Walkthroughs. Their time to shine was at the end of the project lifecycle. Their job was to test the near-finished product and find bugs. The core problem was the tester did defect detection. After every requirement was written and all the code was wrapped up and tied with a nice bow, testers found issues and logged them so they could be fixed. The measurement and cleanup of quality was at the END of the project lifecycle.
QA Process in Agile Testing
With Agile, things have assuredly changed for the better – even if “there is a lack of a good testing approach that fits within agile development methods.” This is primarily because agility shifts focus from defect detection (at the end of the project) to defect prevention (throughout the project). Quality needs to be built in from the beginning and in order to do that, we need a mindset change. With that change, we must shake things up on our teams. Gone is the final push to execute hundreds of tests weeks before Go Live. QA’s role has changed, again, and for the better. QA is not dead. Rather, it is more alive than ever. Quality permeates throughout every agile crevice. On a mature agile team, we don’t wait until the end to measure quality. Quality is built into each task that each member of the team performs during iteration. Agile didn’t kill QA. It gave it new life by expanding the scope of who is responsible for quality on the testing team. The QA process in agile is no longer relegated to the end and is incorporated from the beginning.
Since quality is everyone’s responsibility in agile, let’s talk about how a team can build in quality. Shaun Bradshaw and Bob Galen identified 13 patterns testers need in order to move from “doing” agile to “being” agile. “Doing” agile means you are focusing on tactics, ceremonies and techniques, while “being’’ agile focuses on team mindset and leadership mindset. Here we will focus on two of the thirteen patterns and dive into the behaviors associated with these patterns.
Pattern 1: Whole-Team QA Ownership
Mature agile teams, and especially the testers on those teams, understand that everyone on the team owns quality. The behaviors associated with Whole Team QA Ownership include removing silos and opportunistic pairing.
Removing Silos
Members of an agile team can’t think in terms of silos. Everyone is responsible for testing and quality. Before agile, the project team was broken down into silos. In contrast, agile teams avoid silos by:
- Removing statuses such as “Development Complete” or “Test Complete”.
- Creating healthy relationships between QA and Development
- Ensuring teams have more T-shaped people and not I-shaped people. T-shaped people have a core expertise but can-do other things that are outside of their general skill set. For example, I am a tester, but I could create acceptance criteria too. I-shaped people will only do things they are good at (e.g., Testers only test, developers only develop, etc.).
Opportunistic Pairing
Pairing is frequently discussed as having two developers’ pair together to develop a single feature, but the reality is pairing can come in all shapes and flavors. Mature agile teams can look for opportunities to pair a developer and tester, two testers, or even two developers. Many teams find a great deal of value in getting a developer, tester and product owner together, also known as the Three Amigos. Opportunistic pairing allows each of these roles to gain a better sense of what their teammates do. Pairing different roles together also reduces the need for rework. If a tester and developer pair during unit testing, for example, the tester understands what the developer thinks is important to validate and what they plan to verify. The tester could also recommend other unit tests to the developer if they identify major gaps in the testing. Finally, the tester also has a better idea of areas needing more focus during functional testing.
Pattern 2: Quality on all Fronts
The primary focus in this mindset is quality must be built in anywhere and everywhere. For example, User Acceptance Criteria has to be reviewed for clarity and testability. Developers may want to take a Test Driven Development approach. This could even mean testers discuss, with the whole team, what “just enough” testing would be for the iteration since we may not be able to test everything. By having these types of discussions and bringing the entire team onboard the Quality Train, it shifts quality ownership to the team as a whole instead of the responsibility of the tester only. Everyone must be onboard, working toward defect prevention instead of defect detection.
I hope I’ve shown that QA in agile is not dead; it simply doesn’t look the way it did traditionally. Quality shouldn’t be the responsibility of one or two members of the team toward the end of a project – looking for problems that were already created. Rather, the QA process in agile has allowed us to focus on defect prevention by building quality into everything we do as a team and ensuring everyone on the team is responsible for Quality throughout the development process.
¹World Quality Report 2019-2020 can be downloaded from https://www.microfocus.com/en-us/marketing/world-quality-report-2019-20
Up next:
- Quality in Testing: Everyone’s Responsibility >> Read
- Building a Quality Software QA Team: Quality at Every Level >> Read
Want to improve your overall quality assurance software development?
Learn more about our software test management workshop to ensure quality in your testing processes.
