Testing and Quality Assurance in the Workplace

Depending on the company you work for and the project you're working on, you and your peers can have one of several common names that describes your group's function: Software Testing, Software Quality Assurance, Software Quality Control, Software Verification and Validation, Software Integration and Test, or one of many others. Frequently these names are used interchangeably or one is chosen over the others because it sounds more "official"Software Quality Assurance Engineer versus Software Tester, for example. It's important to realize, though, that these names have deeper meanings and aren't necessarily plug-in replacements for each other. On one hand there's the philosophy that "it's only a name," that what you ultimately do in your job is what counts. On the other hand, your job title or your group's name is what others on the project team see. That label indicates to them how they will work with you and what expectations they will have, what deliverables you will provide to them, and what they will give to you. The following sections define a few of the common software-test-group names and should help clarify the differences among them.

Software Testing

It can't be emphasized enough, so here it is, one more time:

The goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed.

Throughout this book you've learned how to accomplish this goal and the reality and limitations in doing so. Maybe you've realized by now (and if you haven't, that's okay) that software testing can be simply described as an assess, report, and follow-up task. You find bugs, describe them effectively, inform the appropriate people, and track them until they're resolved.

NOTE

The definition of a software tester's job used in this book actually goes a step further than assess, report, and follow-up by tacking on the phrase "and make sure they get fixed." Although there are test groups that would replace this phrase with simply "and report them," I believe that to be an effective tester you need to take personal responsibility for the bugs you find, tracking them through their life cycle, and persuading the appropriate people to get them fixed. The easy way out is to simply stick them in the bug database and hope that someone eventually notices and does something with them, but if that's all there was to testing, you could argue why you should bother looking for bugs in the first place.

Being a software tester and working under this charter has a unique and very important characteristic: You aren't responsible for the quality of the software! This may sound strange, but it's true. You didn't put the bugs in the software, you had your project manager and the programmers review and approve your test plan, you executed your plan to the letter and despite all that effort, the software still had bugs. It's not your fault!

Think about it. A doctor can't make someone's fever go down by taking her temperature. A meteorologist can't stop a tornado by measuring the wind speed. A software tester can't make a poor-quality product better by finding bugs. Software testers simply report the facts. Even if a tester works hard to get the bugs he finds fixed, his efforts, alone, can't make an inherently poor-quality product better. Quality can't be tested in. Period.

NOTE

Some companies do believe that quality can be tested in. Rather than improve the process they use to create their software, they believe that adding more testers is the solution. They think that more testers finding more bugs will make their product better. Interestingly, these same people would never consider using more thermometers to lower someone's fever.

Ultimately, if you're working in a group named "Software Testing," it will be your test manager's responsibility to make sure that everyone on the project team understands this definition of your role. It's often a point of contention when schedules aren't hit and bugs are missed so it's one that should be made perfectly clear up front, preferably in the project's test plan.

Quality Assurance

Another name frequently given to the group that finds software bugs is "Software Quality Assurance (QA)." Chapter 3, "The Realities of Software Testing," cited the following definition of a person in this role:

A Software Quality Assurance person's main responsibility is to examine and measure the current software development process and find ways to improve it with a goal of preventing bugs from ever occurring.

Now that you know a lot more about software testing, this definition probably sounds a lot more scary than when you first read it back in Chapter 3. A Software QA group has a much larger scope and responsibility than a software testing groupor at least they should according to their name.

The definition of assurance^[2] is "a guarantee or pledge" or "a freedom from doubt," so a QA group's role is to guarantee, without any doubt, that the product is of high quality. You can see why, if you're really a testing group, that you don't want to assume this supposedly more "prestigious" title. Allow a bug, any bug, to be found by a customer and you've failed in your job.

^[2] The American Heritage Dictionary of the English Language, Third Edition.

You may be wondering, if software testing alone can't guarantee a product's quality, what a Software QA group would do to achieve it. The answer is having nearly full control over the project, instituting standards and methodologies, carefully and methodically monitoring and evaluating the software development process, feeding back solutions to the process problems they find, performing the testing (or overseeing it), and having the authority to decide when the product is ready to release. It may be an oversimplification to say that it's like having a project manager who's primary goal is "no bugs" as opposed to keeping the product on schedule or under budget, but it's a pretty good description.

You'll learn later in this chapter that moving from software testing to software quality assurance is a gradual process, sort of achieving increasing levels of maturity. It's not a single-step functionyesterday you were a tester and today you're a QAer.

Actually, some of the skills you've learned in this book can be considered software QA skills depending on where you draw the line on bug prevention and where the separation occurs between an internal failure and an external failure. If the goal of software QA is to prevent bugs, you could argue that performing static testing on the product spec, design documents, and code (Chapters 4, "Examining the Specification," and 6, "Examining the Code") is a type of software QA because you're preventing bugs from occurring. Bugs found this way never make it through to later be found by the testers testing the finished software.

TOTAL QUALITY MANAGEMENT

You may have heard of a quality approach known as Total Quality Management (TQM) or Total Quality Control (TQC). The basic philosophy behind this approach is that having a centralized quality assurance group that's responsible for quality isn't feasible because the people doing the workwriting the code or creating the widgetsaren't responsible for quality and therefore won't try to achieve it. To create quality products, a quality culture needs to be instituted from management on down so that everyone shares the responsibility for quality.

Although TQM/TQC has great implications to the mission of an existing Quality Assurance group, it doesn't eliminate the need for software testing. Quite to the contrary, the software testing role in such an environment is more clearly defined. Despite the best efforts of any process, software is still created by people, and people make mistakes. There's still a need for a group to concentrate on looking for bugs. They may not find many, but that's a good thing!

Other Names for Software Testing Groups

Depending on where you work, your test group may use one of many other names to identify itself. Software Quality Control (SQC) is one that's frequently used. This name stems from the manufacturing industry where QC inspectors sample products taken off the manufacturing line, test them, and, if they fail, have the authority to shut down the line or the entire factory. Few, if any, software test groups have this authorityeven ones that call themselves Software QC.

Software Verification and Validation is also commonly used to describe a software test organization. This name is one that actually works pretty well. Although it's a bit wordy, it states exactly what the test group is responsible for and what they do. Look back to Chapter 3 for the definitions of verification and validation. It's even possible to have two groups, one for verification and one for validation.

Integration and Test, Build and Test, Configuration Management and Test, Test and Lab Management, and other compound unrelated names are often a sign of a problem. Many times the software test group takes on roles (voluntarily or not) that are unrelated to testing. For example, it's not uncommon for a test group to own the job of configuration management or building the product. The problem with this is twofold:

• It takes away resources that should be used for testing the product.

• The test group's goal is ultimately to break things, not to make things, and owning the software's build process creates a conflict of interest.

It's best to let the programmers or a separate team build the software. Testing should concentrate on finding bugs.