| Article Index |
|---|
| The Path to Successful Defect Tracking |
| Page 2 |
| Page 3 |
| All Pages |
After Implementation
Once you have implemented the defect-tracking system (whether you have purchased a
system or built one in house), you are ready to begin entering and assigning defects.
However, what do you do with this data? After all, you will soon have a database full of
useful information about your software products, including the number and severity of
defects found by both your development staff (most likely QA Engineers) and technical
support personnel.
As stated in the introduction, this data can help answer questions like:
1. What areas of the application are most vulnerable to defects (For example: Is the UI
stable? Does the backend database connection work reliably?)
2. Which developers have the most reopened bugs?
3. Which QA engineers find the most defects? Which find the most severe defects (as
opposed to superficial issues, such as spelling and other typographical errors)?
In addition, upper management may want a report on the quality and stability of your
product(s). As long as you are storing your data in an ODBC-compliant database, you
should be able to easily extract this data into spreadsheets, which can in turn be formatted
and sorted in several ways.
Based on these reports, management can make decisions like whether to upgrade the
development staff, place additional resources on specific (more vulnerable) areas of the
system, and perhaps most importantly, determine the status of a project.
Conclusion:
Many companies make the mistake of not spending enough time choosing a defecttracking
system. Think carefully about what information is most important, who will be
using the system, and how you will report the results. The bottom line is that a strong
defect-tracking system is critical to the success of a software development organization.
Subscribe to this comment's feed
| < Prev | Next > |
|---|
