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
   194   195   196   197   198   199   200   201   202   203   204