Better Software - September 2008 - (Page 32) Table 1: Condense example Defect remarks CheCklist Here is a mnemonic to use as a mental checklist for self-inspecting your defect report. The first letter of each item on the checklist spells CAN PIG RIDE. These ten points ensure that your defect reports answer the questions that will be of most benefit to your organization: • Condense • Accurate • Neutralize • Precise • Isolate • Generalize • Re-create • Impact • Debug • Evidence It is not just good technical writing skills that lead to effective defect reports. It is more important to make sure that you have covered the essential items that will be of most benefit to the intended audience of the defect report. table 1. Second, don’t add in extraneous information. It is important that you include all relevant information, but make sure that the information is relevant. In situations where it is unclear how to reproduce the problem or the understanding of the problem is vague, you will probably need to capture more information. Keep in mind that irrelevant information can be just as problematic as too little relevant information. • Do you really understand how this is supposed to work? Make sure that you understand the numerous test-case influences and consider their roles in the perceived bug you are reporting. This is one area that quickly separates the experienced tester from the novice. If you are unsure about the validity of the problem, it may be wise to consult with an experienced tester or developer prior to writing up the problem. Don’t be afraid to write up problems, but do your best to ensure that they are valid problems. When you discover that you have opened an incorrectly reported problem, make sure that you learn from the experience. ACCurAte Make sure that what you are reporting really is a bug. You can lose credibility very quickly if you get a reputation of reporting problems that turn out to be setup problems, user errors, or misunderstandings of the product. Before you write up the problem, make sure that you have done your homework. Consider the following: • Is there something in the setup that could have caused this? For example, are the correct versions installed and all dependencies met? Did you use the correct login, security, command/task sequence, and so forth? • Could an incomplete cleanup, incomplete results, or manual interventions from a previous test cause this? • Could this be the result of a network or some other environmental problem? www.StickyMinds.com neutrAlize State the problem objectively. Don’t try to use humor, and don’t use emotionally charged zingers. What you think is funny when you write the defect may not be interpreted as funny by a developer who is working overtime and is stressed by deadlines. Using emotionally charged statements doesn’t do anything for fixing the problem. Emotional statements just create barriers to communication and teamwork. Even if the developers doubted you and returned your previous defect and now you have proof that you are correct and they are wrong, just state the problem and the additional essentials for effective Defect remarks Condense Say it clearly but briefly. First, eliminate unnecessary wordiness, as shown in 32 BETTER SOFTWARE SEPTEMBER 2008 http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.