defect reporting

In many projects, finding defects is easy but getting them fixed quickly and correctly can be a big problem. As a test professional armed with test plans and automated tools, you can detect and report reams of bugs. But in the end, product quality is not judged by the problems found, but by the problems fixed. Until a time when robots fix defects, testers must convince programmers to research and fix problems. How do you make certain that the important defects you find are corrected properly? How do you get and keep the attention of management to sell them on the fixes you think are essential? In this presentation, Margaret Ramsey discusses the people issues in reporting and selling your defects to both management and developers.

Whether you call them bugs, defects, issues, or Test Incident Reports (TIRs), a tight schedule with unrealistic project goals requires you to record, track, and report on software problems quickly and accurately. Based on experience with projects operating in chaos, Marc Rene presents some real-world examples of how TIR data was collected, tracked, and presented to management for a quick and concise status of a project.

Why is it some testers get a better response from developers than others? Part of the answer lies in their defect reports. But following a few simple guidelines can smooth the way for a much more productive environment. That's because the objective shouldn't be to write the perfect defect report, but to write an effective defect report that conveys the proper message, gets the job done, and simplifies the process for everyone. It's important that you use this report to ask and answer the right questions. Kelly Whitmill gives you a quick mental inspection checklist you can reference each time you write a defect report. You'll walk away with information that can make a significant difference the day you get back to work, on a topic that's often overlooked in the industry.

Once development reaches "code complete," the testing team takes over and drives the project to an acceptable quality level and stability. This is accomplished by weekly build cycles or dress rehearsals. The software is graded based on found, fixed, and outstanding errors. Development strives to increase the grades in each build--improving the quality and stability of the software. Learn how to use this "dress rehearsal" process to build team morale, develop ownership by the entire development team, and ensure success on opening night.