“We’re QAing it right now.”
Ow. That just makes me cringe. For the record, QA is a noun. Please don’t verbify it. It’s the verbifying that really gets to me.
There’s another reason that phrase bugs me. It’s an example of taking a perfectly good word, “test,” and substituting a high-falutin’ word instead.
Whether or not I like it, it’s a fact of life. In most organizations I see, when someone says “QA” they mean “test.” The people who have titles involving “QA” usually do Test-related activities. Their primary concerns are designing and executing tests, reporting bugs, and other testing tasks. HR departments everywhere would be thrown into a complete tizzy if they had to re-title everyone who happened to have a QA title but a Test-related job. Furthermore, those same folks with Test-related jobs would probably have a fit too. QA is usually a higher pay grade.
However, there are other people with QA tasks who are quick to point out that Testing is a form of Quality Control. QC. Not QA. These folks are usually Process QA people. They work on process improvement and defect prevention. They are concerned with best practices, process enforcement, quality gates, artifact inspections, and root cause analysis. Process QA people make sure software is good by making sure that the process that produces the software is good.
Process QA people rarely do testing; Test QA folks rarely do process work. They’re really two different jobs with an unfortunate title overlap.
You may be wondering “Why is this important?”
You may also be thinking, “Wow. This is a really stale. Haven’t we been over this a gazillion times? Is Elisabeth so strapped for topics that she’s revisiting themes from 10 years ago?”
Well, no. I’m talking about this now because when someone asks “What’s the role of QA on an Agile team?” it makes a difference if they’re asking about Process QA or Test QA.
Many of us have written a bunch about how testers can work on Agile teams. Just a few examples:
- my PNSQC paper, “Agility for Testers” and my follow on post Agile Testing.
- Lisa Crispin and Tip House’s book, Testing Extreme Programming
- Brian Marick’s “Agile Testing Directions”
- Jonathan Kohl’s “Exploratory Testing on Agile Teams”
There are many more, but that’s a quick sample.
These articles and books address the “Role of QA in Agile?” question for the people who are Test QA. But few have discussed how Process QA fits into Agile. And the Process QA folks are starting to ask the question.
I’m still figuring out how to express myself clearly on the topic of how Process QA folks fit into Agile, so that’s a post for another day. In case you’re curious, I’ll give you a preview: I’m wary of finding a way to fit Process QA into Agile. That’s because I think that Process QA folks often become process cops, and I think that an Agile team that needs a process cop is an Agile team that needs to adjust their process. When an Agile team needs process cops, it’s a sign that somehow the process is no longer working for the team; instead the team is working for the process.
Hello, Elisabeth. Good post. As a member of the American Society for Quality (ASQ), I often have interesting discussions with software process QA people. Invariably, they say something like “oh … testing … yeah, that’s ok … I guess … but really, it’s too late in the cycle, you need to do stuff earlier.” So this is something I have been ruminating on for some time.
My father in law is also an ASQ member and a automotive quality engineer. His take on it is that the role overlaps with management (in a command and control culture) or, well, everyone in a post-modern culture. So I asked “Why do you need the quality engineer then?” and his reponse was this:
Take your average high-quality, world-class, super-empowered shop. Now change the management; say the company is purchased, or purged, or you bring in a VP of SoftwareDev who was very succesfful at a different context and “all this agile stuff” makes him feel out of place.
Without quality people in place, you might have just thrown all that great culture out the window. With quality people in place, you’ve got a chance to preserve the culture. (A similar arguement can be made for why you need heavyweight documented processes)
I’m not 100% sure I agree with him, but he makes some interesting points.
Enought for now, I suppose …
Now that I think of it, that’s the same argument that some people make for literal bureaucracy – a heavyweight bureau with well-defined procedures can stop an out-of-control leader from destroying an organization. For example, if a senator (or even the secretary of immigration) calls a middle-level bureaucrat and asks to have his buddy-who-lacks-paperwork to be walked through immigration at the airport, the answer will be “No, we don’t do that here.”
Now that I think about that, that’s a pretty confrontational approach to QA …
Hi Matthew,
Thanks for your comments! I think your insight about using the same argument to perpetuate Process QA as to perpetuate a heavyweight bureaucracy is right on target.
The nice thing about Agile practices is that they tend to be self-sustaining. You can take the programmer out of an XP team, but you can’t take the XP practices out of the programmer. Once a programmer really groks TDD, they tend to continue TDDing even if it isn’t one of the team practices. Daily standups, big visible charts, refactoring, and frequent integration are similarly addictive. And that means that an out-of-control leader attempting to toss Agile practices out may well have a mutiny on their hands. And a couple Quality Engineers hollering about Defect Prevention and Early Detection just won’t have the same impact as a full on mutiny.
Elisabeth
Yeah! Gud & fine article .. Now my doubt about QA & QC little bit over.. Still some confusions.. Is the QA people involve in the whole SDLC Process? what is process enforcement ?