Fiona Charles was a tester. After six years of testing for her company, she followed a path to which many testers aspire--she graduated into Quality Assurance (QA). Finally, she got to help prevent bugs, instead of only being able to point them out after a mistake had already been made. By the way, when I say "QA" here, I mean assessing processes and influencing people to improve their processes, rather than the more common usage, which is simply a synonym for "testing."

But Fiona's story doesn't stop there. After doing QA work for a few years, the senior managers who supported her work left the company, and the new managers did not share their appreciation for QA. Schedule pressures caused the processes that everyone had agreed to follow to be thrown out the window. People said that QA was getting in the way. Fiona says she left the company probably five minutes before they would have booted her out. It was such a painful experience that now she avoids QA roles as much as she possibly can.

When Fiona told me her story, I was amazed how similar it was to my own QA story. When I cut my teeth as a tester, I got the impression that testers should naturally move on to a QA role after they're good enough. So when I got frustrated with finding bugs and became convinced that preventing bugs was a higher calling, I insisted on starting a QA team. I drew some process pictures and started a formal inspection process. I studied the masters of the Quality Assurance movement. But somehow everything caved in on me a year later. I honestly don't know why I started getting complaints from management claiming I wasn't doing a good job, but I have a strong suspicion that, like Fiona, I left the company shortly before they were going to throw me out.

Similarities between testing and QA.
Let's explore if QA is really a higher calling for testers, first by looking at the similarities between the roles. One thing is fairly obvious--testers and QA staff need to have a passion for quality. Both must have the ability to temper that passion with a dose of practicality. Soft skills are important for influencing people when you don't have direct control over the product. And since testers often take on some QA-related tasks anyway, they may already have experience doing part of the job.

On top of that is the big frustration that every tester seems to encounter at some point in their career: They can't stand seeing the same mistakes being made over and over again because they know there's a better way to build a product. So the QA team seems like the right place to go.

But what are the differences?
How do testing and QA differ? Testing focuses on product quality. QA tends to be a step removed from the product, focusing on process quality, though QA also can look at product-related metrics. QA requires more knowledge of the entire development life cycle. QA staff has to gain the respect of managers, requirements people, designers, programmers, configuration management staff, and of course, testers. Years of experience as a tester gives some exposure to all of these, but might not make a tester an expert in all of these areas. QA requires even greater soft skills than testing, since they need to gain the trust of people across the whole organization and convince people to change some of the core methods in their jobs.

Testers have tangible deliverables, such as test cases, bug reports, etc. QA folks work more with intangibles such as observing, advocating, facilitating, and influencing. It can be frustrating when the QA analyst gets the feeling that she's even further removed from the tangible aspects of building a quality product than she was as a tester.

What can go wrong?
Here are a few of the problems that someone in a QA role might encounter:

• Doing process work for an organization that isn't mature enough to understand the value of that work. The organizations that need QA the most are the least likely to embrace it. So you have to find an organization that has done enough improvement the hard way to realize that there's probably a better way to do it. Different people have different preferences for the maturity and formality of an organization with which they work.
• Being an advocate of best practices for its own sake instead of helping people solve problems from their own point of view. You can't shove a process down someone's throat and expect it to stay down. The best way to approach change is to help someone discover a solution for a problem he really believes he has. And that means you might not even get credit for your work.
• QA gets in the way. It really does--in the short term. Better processes will pay off in the long term, but only if you get past the resentment you cause by delaying someone's favorite project while a new process is taking hold.
• It's extraordinarily difficult to successfully make massive process changes. The most dependable approach is to make many small improvements over time, which takes a lot of patience. If you do try to change the world rapidly, be prepared to face utter failure.
• When it's time to downsize, or if upper management's philosophy changes, QA is often the first on the chopping block. Don't bother to hang many pictures in your cubicle.

Are you scared away from QA yet?
I believe that there are many good career paths that a tester can follow besides QA. Here are some:

• Management. Get some practice as a test lead, try your hand as test manager, and then look for lateral or upward moves into management.
• Toolsmith. If you want to remain technical and also still want to be steeped in testing, become a test tool expert.
• Consultant. Strange but true, many of the most experienced testers in the industry are consultants.
• Lots of other things with some amount of overlap with the skills you use as a tester--like programming, technical writing, tech support, marketing, etc.

QA might be right for you. I've heard of a few people who are really good at it. If you do take that path, hopefully you'll be better prepared for it now, and if not, I hope you have a new appreciation for the people who do it.

Further Reading:
"Testing, Zen, and Positive Forces," March 15, 2004