News »Browse Articles »
10 Tips to Avoid Writing a Bad Software Defect Report!
0
10 Tips to Avoid Writing a Bad Software Defect Report!
Tech - Arts
As it has been said a million times - even (so-called) thorough testing cannot produce a 100% defect-free software. As long as there would be softwares there would be defects in the software. And as long as testers would keep finding defects they would have to report it in some form of Defect Report/Bug Report, so that further actions could be taken on the defects. As Dr. Cem Kaner puts it - “The aim of writing problem report (defect report) is to get the defects fixed”.
Just imagine a tester who is very efficient and skillful in finding defects in the application that he is testing but is very poor in reporting them. Is it not something like cooking a great dish but serving it in an old dirty plate that leaks and messes the dining table? What is the point of taking your time and putting your effort to prepare a tasty dish if your guests can’t enjoy its tastefulness (due to the bad way in which it is served)? The same can happen if a tester is good at finding important defects quickly but ends up logging bad defect reports/bug reports! Chances are more that the seriousness of his reported defect might go unnoticed [worst still, the defect might get turned down as “Rejected” since the programmer looking at the defect report finds it hard to figure out the bug].
The work of a software tester on software projects is much like the technicians at a diagnostics center do. There is no scope for ambiguity when a medical diagnosis is reported. Before a technician reveals his diagnosis, a lot of symptom analysis, critical thinking, cause-effect analysis, syndrome of related diseases and mind work goes into it. A diagnostics technician has to be very accurate in reporting the problems as he diagnoses. “Patient XYZ has perfect symptoms of acute dual renal failure” might kill the patient just out of shock. In any field, effective reporting is much of an art.
Similarly, when diagnosing issues with software while testing, there is hardly any scope of ambiguity. As testers, we have to keep in mind that each bug reported involves some work for programmers. They have to understand the context of the issue, try to reproduce it and resolve it after it is reproduced. Unless your defect report is clear and precise, the programmer might find it a tough call to reproduce the defect. And unless the programmer is able to reproduce the defect, there is not much he can do about it to fix it. But non-reproducibility of the defect at the programmer’s machine does not mean that the defect is gone! It (the defect) is still sitting there (in the code, the design or the architecture of the project). And there begins the problem. Many a times, a project manager needs to understand what are the severe issues open and manage the project accordingly. But he might miss to consider the severity of your reported defect, as it was badly reported in the first place by you and the manager can’t reproduce it!
For this, testers must distinctly and succinctly report each of the finding with appropriate severity and priority assigned. [Note: When I say that your defect report must be with appropriate severity and priority, you (the tester) must understand that these are perceived severity and priority and are subjected to change in future if the person evaluating this defect (can be the system analyst, your test lead, the test manager, the project manager) thinks that a different severity/priority would be more appropriate under the given context.] Suppose you are a programmer and you see a bug report stating, “The Parser is unreliable” or “The values in the City combo box are not proper”. How would you react to it? Words like *unreliable* and *proper* are relative. What is proper to me might not appear as proper to another tester. So use of words like these can make the defect report ambiguous and the programmer reading the report can get confused!
Following are few pointers that can be kept in mind to effectively report software issues:
1. It`s all in a Name: Each defect should be clearly identifiable by the defect title. Keep it short, and yet the defect report title should give a descriptive summary of the defect. Use meaningful defect titles that reveal the point of the report without further reading; the key here is to create microcontent that can fare well on its own. Give the.......
Source:
http://software-testing-zone.blogspot.com/2007/12/tips-effective-bug-defect-repo