Many people in this profession prefer to be called "software testers" rather than "software quality assurance" (QA) workers. They point out that quality can only be assured by the entire development team, and that software testing is rightly defined as quality control (QC). QA work is process work, but software development has historically lumped QC and QA together. On a lot of projects this means that the traditional QA role is set up for failure, being the ones on the project whose responsibility it is to criticize the work only after the work is done. As Antony Marcano once said, "Unfortunately, in the software industry, all too many teams don't realize their process doesn’t work until the testers find all the ways in which the product doesn't work ... maybe that's why software testing has come to be known as QA."

There are important differences between the work of testing software and the work of QA. But, there are important reasons why testers are in a good position to exercise excellent quality assurance.

Definitions and Confusions
Software testing is the act of investigating the behavior of software products in order to supply information to the stakeholders about the fitness of the software for use in particular context. Software testing is not a phase in the development lifecycle.

QA is analysis of the software development process for the purpose of increasing or maintaining the quality of the software. QA is all about process, of which testing is only a small part.

In the world of manufacturing, for a product to roll off an assembly line, measurements must be taken (testing or QC), and if parts do not conform to spec, the reason must be found (process analysis or QA).

But we are discovering that analogies from manufacturing often map poorly to software development practice. Ten years ago, implementing ISO9000 processes and Six Sigma processes for software development was very popular. Today, many software development organizations see such approaches as expensive and wasteful. Software quality assurance for modern development teams demands a more subtle approach, and testers can be a big part of that work.

Key Aspects of Testing
Good software testing shares some focus with software development. Both require close reading of the software requirements. Both are closely involved with the code as it comes to implement the requirements. Both are closely concerned with avoiding software failure in the production environment.

But good software testing deviates from development in a few important ways. Developers typically work in a very limited area of the code base for long stretches of time, while testers are very concerned with the behavior of the system as a whole. Developers are deeply concerned with the technology of the software, while testers tend to be more concerned with the business implications of the software. The tester typically is a proxy for the eventual consumer of the software product and works accordingly.

This means that testers often are the only role on the project team to have deep and close exposure to every aspect of the software—from conception to development to deployment to ultimate use.

Learning QA
But good testing does not automatically mean good QA. Just because testers are familiar with the entire process does not mean they are in a position to improve it—or even influence it at all. That work takes an entirely different set of skills and a whole new area of knowledge.

For one thing, it helps to have a solid grasp of the history of software development processes, what problems each process was intended to address, and what problems each process introduced. A brief list of well-known software development processes includes: staged (waterfall) processes, with gated handoff requirements; V-models, with work going on simultaneously by all participants; spiral models; and iterative models. It is also helpful to know about general subjects like requirements management, code design, validation, verification, deployment strategies, and other aspects of delivering software.

There is nothing to stop a tester from learning these things. And a tester, in the course of his work and in the course of his career, will be able to learn and practice bits of what he reads about these processes.

Gentle QA
Changing process is hard. Changing process quickly can be devastating. A good QA person will look for "inflection points," that is, opportunities where a series of small changes can bring about higher-quality work, higher-quality products, and higher-quality process.

Some processes have such inflection points built in. For example, the agile Scrum process demands a retrospective at the end of each iteration, where the whole team analyzes the work of the previous iteration, identifies issues that caused problems for the team, and commits itself to fixing those problems. The cumulative effect of such frequent process improvements becomes dramatic over time.

A QA person is in a position to take advantage of practices like retrospectives to guide the team's work along lines that are known to be effective.

The Quality Police
Bret Pettichord's excellent and widely quoted essay "Don’t Be the Quality Police" is worth reading. Pettichord argues that attempting to punish poor performance in the name of quality is bound to backfire.

QA practitioners—whether or not they are also testers—do not manage the project, nor do they have power to hire or fire employees, nor do they have control over budgets. QA is not a position of power.

But QA can be a position of great influence. The QA worker can help the team instead of holding it back. The QA worker can streamline the process instead of being a drag on it. The QA worker can recommend great new information instead of hoarding secrets. Done well, QA can be a valuable member of any kind of software development team.

Use Your Power for Good
QA in software has a bad reputation because of its poorly conceived conflation with QC and because of its misguided attempts at policing projects in the name of quality. But slowly, advocates of good process, good communication, and good practice are turning that reputation around. Many of these advocates are testers or have a background in testing. Seek them out, and join in the conversation yourself.