Better Software - September 2008 - (Page 35) 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. debuG What will the developer need to be able to debug this problem? Are there traces, dumps, logs, and so forth that should be captured and made available with this defect report? Document what has been captured and how it can be accessed. evidenCe What evidence exists that will prove the existence of the error? Have you provided both the expected results and the actual results? Is there documentation that supports your expected results? Since you are writing a problem report, it is obvious that you believe there is a problem. Provide anything you can that will convince others that this is a valid problem. Evidence may take the form of documentation from user guides, specifications, requirements, and designs. It may be past comments from customers, de facto standards from competing products, or results from previous versions of the product. Don’t assume everyone sees things the same way you do. Don’t expect people to read between the lines and draw the same conclusions as you. Don’t assume that three weeks from now you will remember why you thought this was a bug. Think about what it is that convinced you that this is a bug and include that in the report. You will have to provide even more evidence if you think there is a chance that this situation may not be readily accepted by all as a valid bug. Defect abstracts the full description that gets included in reports. It is the abstract that the project managers, screeners, team leads, and other managers look at when trying to understand the defects associated with the product. The abstract must be concise and descriptive and convey an accurate message. The abstract is usually very limited in length. Because of the space limitations, abbreviations are OK and short, accurate messages take priority over good grammar. A good use of keywords is essential since many searches are based on the abstract. Keywords such as abort, hang, typo, and so forth are both descriptive and useful as search words. Where space permits, it is helpful to mention the environment, the impact, and any of the who, what, when, where, and why questions that you can address in such a short space. Be as specific as possible. For example, the following abstract is true but doesn’t provide nearly as much information as it could: Abstract: Problems found when saving and restoring data member. Perhaps this would be a more descriptive abstract: Abstract: xyz’s save/restore of data member on WinNT fails, data corrupted. You can never get everything you want in an abstract, so here is a list of items and tips that I try always to include: Mandatory: • Concisely, explicitly state what the problem is—not just that there is a problem. Recommended (space permitting): • Use meaningful keywords. • State environment and impact. • Answer who, what, when, where, why, and how. • Using abbreviations is OK. www.StickyMinds.com • Grammar is secondary over conveying the message. • Don’t use defaults. summary Testers spend a significant amount of time seeking out and discovering software problems. Once detected, it greatly enhances productivity to report the defect in such a way as to increase the likelihood of getting the problem fixed with the least amount of effort. Making sure that the proper information is provided is more important than superior writing skills. The ten topics described in this paper will go a long way toward helping you provide the right information in every defect report. The better you are at writing defect reports and abstracts, the more likely it is that problems will actually get fixed in a timely manner. Your credibility and value-add to the business will increase as developers, managers, and other testers are better able to do their jobs because your defect reports are well written and reliable. {end} Sticky Notes For more on the following topic go to www.StickyMinds.com/bettersoftware. n Further reading The short, one-line abstract that gets associated with most defects can be a very powerful communication tool. Oftentimes, the abstract is the only portion of the defect that gets read by the decision makers. It is the abstract and not SEPTEMBER 2008 BETTER SOFTWARE 35 http://www.StickyMinds.com/bettersoftware 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.