4.6. Finishing Touches: Capturing Bug Data for Analysis
You now have a fully adequate bug tracking database that you can use to manage bugs through their entire lifecycle, to produce summary reports for management and detail reports for developers, and to keep track of who is responsible for moving bugs forward. You might want to design additional reports or make some cosmetic changes, but the database is essentially complete. To gather some additional data that can bring bugs into sharper focus, however, I recommend that you add a few more fields.
4.6.1. What the Bug Relates To: Subsystem, Configuration, and Quality Risks
Some of the data you might want to gather would help you understand what the bug is related to. In other words, what is the context for the bug? There are a number of data elements you could gather here, but I prefer to focus on three.
Adding a Subsystem field allows you to captures which component of the system bears the brunt of each bug's symptoms. In our DataRocket case study, for example, subsystems might break down as follows:
Mainboard.
The CPU, the motherboard, the memory, the on-board fans, and common built-in controllers for the USB, parallel, serial, mouse, and keyboard ports.
Video.
The video card and, if bundled, the video cable and monitor.
SCSI.
The SCSI adapter, the internal cables, the external cables, the RAID hardware, the tape drive, and the CD-RW drive.
Network.
The controller configuration, which can involve one or more cards.
Telecommunications ...
Get Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
