Two mind traps
Two of the most important functions of a software tester are to identify defects and to help prevent them. It is the role of the software tester to act as a critic of the product and as a critic of the project. As a critic identifying defects, it is easy to fall into negative mental patterns of all kinds. There are two patterns that testers seem to manifest more than any others: feeling they must find every defect and feeling every defect must be fixed.
Can you find every defect?
The first trap is to believe that testers should be able to find every defect. Testers are competent and experienced professionals, and if the team releases a defect to production, it must be the tester's fault for not identifying the issue in time. This belief is particularly destructive when it permeates the whole team and everyone on the team believes that the testers should be able to find every bug in time to prevent their escape to production.
Even those testers who know that this is a fallacy take it hard when a defect escapes to production. When it happens (and if it has not happened to you yet, it is only a matter of time) remember: the tester may have failed to find the defect, but there was a long chain of events that led to that issue, of which the tester is only a part. As a professional critic of software, a bug escaping to production is an opportunity for testers to contribute to improvements in the overall process that led to that issue. Do not feel responsible for bugs in production; instead, consider bugs released to production as opportunities for improving testing techniques and for improving the process for the whole team.
Do you care too much?
The second trap is to believe that every bug that testers find should be fixed. Competent software testers care deeply about product and process quality. Having discovered a defect or an issue in the software or in the way the software is made can become a constant irritant if the issue is not fixed.
Just as it is impossible to find every defect, it is also impossible to fix every defect. It is not the tester who decides the value of the team's work. It is often more valuable for the team to create new features than to fix defects. Sometimes the cost to fix a defect exceeds the value of the improvement to the customer.
As a critic of software products and processes, it is important to remain dispassionate about the issues found by testing. As a professional software tester, it is still important to practice "bug advocacy," the technique of exploiting a defect so as to cause the maximum amount of damage to the system, and then reporting those consequences. However, being emotionally involved as an advocate for fixing particular defects will take an enormous emotional toll on a tester.
The role of critic
There is another important aspect of being a critic that is rarely discussed in software testing It is not only an important aspect of the work, it is also a powerful way to avoid the two testing traps. Software testers become fixated on defects and problems, sometimes to an unhealthy degree. It can come to seem as if the product is nothing but a depressing mass of unfixed defects.
Remember, a true critic is a dispassionate reporter of both the good and the bad aspects of the work. As a software tester, it is important to point out not only the defects, but also the aspects of the work that are of particularly high quality. A tester who makes the effort to publicly point out a particularly clever aspect of the user interface, or a complex transaction that is faster than expected, is a tester who can avoid these two traps. Such a tester is also likely to be more valued by the rest of the team.
People who believe that software testers should find every bug are headed for disappointment, resentment and unhappiness, as are people who believe that every bug found should be fixed. Instead, if we believe that the whole team is involved in the software process from beginning to end, and if we believe that software testers are valuable critics of both the good and the bad aspects of software, then we are certain to be happier and more productive in our work in creating software.
About the author: Chris McMahon is a software tester and former professional bass player. His background in software testing is both deep and wide, having tested systems from mainframes to web apps, from the deepest telecom layers and life-critical software to the frothiest eye candy. Chris has been part of the greater public software testing community since about 2004, both writing about the industry and contributing to open source projects like Watir, Selenium, and FreeBSD. His recent work has been to start the process of prying software development from the cold, dead hands of manufacturing and engineering into the warm light of artistic performance. A dedicated agile telecommuter on distributed teams, Chris lives deep in the remote Four Corners area of the U.S. Luckily, he has email: [email protected]