Page 199 -
P. 199
requirements specification would be essentially unreadable to, say, a college student or
temp with no software engineering background. How would such a person then be able to
design a test strategy to verify it?
Many people mistakenly believe that software testing is a stepping-stone to programming.
This is complete nonsense. The skills are completely different, and a good programmer will
not learn any more about programming by testing software than a tester would by pro-
gramming. They are different jobs with different skills. Nobody suggests that a program-
mer should first be a requirements analyst or project manager before beginning to
program. But for some reason, many people suggest exactly this about those who work in
quality assurance. All of those jobs have different skill sets, and all are necessary in order
for a team to develop software. A good project manager will help her organization see that
no one of those jobs is more important than any other.
Another myth is that testers have to be “nasty.” The thinking behind this is that testers
must enjoy criticizing other people about minute details. (This is also often what people
mean when they say that testers should be “detail-oriented.” Shouldn’t everyone involved
in software development be equally detail-oriented? Details can make or break the
project.) In truth, testers do not need to be nasty; rather, they should be scientifically-
minded. Each test case is really an experiment: if the user interacts in this way, does the
software produce the desired results? The testers really want the software to pass, and
would prefer to be able to move on to the next test rather than to have to enter a defect.
The most common myth is that testers want to keep the organization from releasing soft-
ware, and want to criticize the programmers who built it. It is common to talk about a
“battle” between programming and QA, in which there is a lot of tension and competition
between the two groups in the organization. This myth is highly counterproductive,
because it drives a wedge between software engineers working toward the same goal. A
good tester simply wants the truth about the software to be known, so that responsible
and accurate decisions can be made about its health. Testers do not want to keep the soft-
ware from being released; they just want the stakeholders and managers to make an
informed decision about releasing it.
In other words, testers don’t want to be mean to the programmers; they want to help
them make the code better, so that everyone can be proud of the product. There is no
mystery to what motivates a good software tester. Testers want to do a good job and take
pride in a well-engineered product, just like all other software engineers. It’s their job to
catch defects; if they miss defects, they look like lousy testers. They aren’t hired to abuse
programmers; they’re hired to “abuse” software—by people who have the software’s best
interests in mind. Software testers certainly do not want to make specific comments about
individual programmers. In fact, when they are testing, they rarely even know who wrote
the code that broke. All a tester wants to do is report that taking certain action with the
software does not yield the results she expected. It’s up to management to decide how to
handle that.
SOFTWARE TESTING 191