QA as the ingenious knight Don Quixote of La Mancha

Every now and then I hear someone complain about poor quality in agile development while invoking QA engineers and their crucial role. The myth is the belief that quality in agile development is primarily the responsibility of QA. Here's a sports analogy. Having the best goalkeeper in the world tells you nothing about how many goals you'll concede. Defense is the whole team's job. The goalkeeper, like the QA engineer, is a kind of conductor with the clearest view of what's happening. Architecture and other aspects of development are similar. Whatever aspect you pick, the whole team is responsible for it. On a team that pushes the quality of its software to the background, even a QA engineer with a shotgun aimed at the back of every developer's head won't help. So what is QA's role in agile development?

First, it's as important as any other role on the team. Just as you can't play without a goalkeeper, with a few exceptions such as pulling the goalie in hockey, you can't operate without someone in QA. That's true whether the code you produce has one bug or ten. The better the code, the more the QA team member's role changes. In every case the role is indispensable, because QA can at least offer a different perspective on the problem. You can look at the QA role in terms of how experienced the team is, where experience goes hand in hand with emphasis on quality. The more experienced the team, the more attention it gives quality.

An inexperienced team

QA keeps the developers in line. It's an authority that decides what does and doesn't meet the quality criteria and also mentors the developers. QA explains the role of tests, helps introduce automated tests (the carrot) and maintains discipline around writing tests. Of course, when the tests fail, an important part of the job is to call the developers to account. Inexperienced teams often want to write tests but don't know how. That's why QA needs to teach as well as enforce. The turning point comes when the team starts to understand what tests contribute as an integral part of development and stops questioning their value with excuses about lack of time, for example.

A moderately experienced team

The team understands the advantages and appreciates what tests contribute, and QA's job is to push it to the next level. That might mean more specialized tests for performance, endurance or various disaster scenarios. QA again explains the ideas and helps put them into practice. Automating the entire test process in a test pipeline starts to matter more, as do measuring quality and tracking trends. QA is still indispensable when estimating regression risk and defining acceptance tests, for example. In general the role gradually shifts from mentor to partner.

An experienced team

The test pipeline is set up, the team coaches itself on testing and the QA role has moved on. QA is a partner who provides support with testing. The role is crucial because QA can bring a perspective free of the assumptions of the people who built the software and help with harder cases, such as testing in a specific environment or covering particular edge cases. QA no longer acts as an enforcer. Developers understand very well that QA makes life easier for them rather than putting obstacles in their way.

The lines between team experience, the QA role and particular QA activities can blur. They often depend on other circumstances too, such as company culture and processes. I'd like to emphasize once more that QA alone can never ensure quality unless the development team embraces it as an integral part of its work. In any other case, QA is playing the part of the ingenious knight Don Quixote of La Mancha.