There are some who recommend against using a defect tracking system. Instead, it is recommended that when a bug is found, it is fixed immediately. While that is certainly one way of preventing an ever growing inventory of defects, the tracking of an inventory of defects is one of the smallest benefits of a defect tracking system. Overall, a defect tracking system serves as a facilitator. It simplifies the collection of defect reports from all sources. It isn’t just the developers responsible for fixing the defects that find problems. Customers, developers working on dependent systems, and testers also find defects. Even if you have a policy of fixing defects as soon as they are found, it isn’t always logistically possible to do so. For instance, if you are currently working on fixing a defect and in the process of doing so you find another one, you don’t want to lose track of it. Thus, a defect tracking system coordinates the collection of defect reports in a standard way and collects them in a well known location, insuring that important information about the functioning of your system is not lost.
A defect tracking system also manages the progress of work through the development life cycle from reporting, to triaging, to assignment, to test development, to completion, to test, to integration, to delivery. It simplifies the answering of customer questions such as “what is fixed in this release” and “what release will the fix appear in.” A defect tracking system also allows for the collection of metrics which aids in the spotting of trends. I have heard from multiple sources that metrics collected from a defect tracking system are worthless because developers will just game the system. That may be true in an unhealthy environment where the metrics are tied to compensation. However, in an environment where developers are actively participating in the improvement of the process, they will want this information in order to help to find and fix problems, including the root cause of individual problems.
Next: Designing Software is the Same Thing as Predicting the Future
4 comments:
I like the idea of root-cause analysis, especially if agile is meant to be a process whereby process is continually adapted for improvement.
Sometimes it's difficult to determine where improvements are best made without some data to analyse. In my opinion gut feeling is good, but it's not always the only solution, especially when you've got to convince others who don't have the same gut feeling.
The other great reason to record defects is so that future developers can use the lessons learnt. Even if you do write new test cases, these might not capture all nuances, and as with any job, people come and go. Creating an environment whereby lessons learnt are captured even if in minor detail helps. (I know this is breaks the peeps over docco view, but that's really argueable from a future peeps point of view.)
Brendan,
Thanks for your comments. Good points! You may also like my updated version of this post which is here: "Adrift in a Sea of Conflicting Priorities And Assignments? Here's a Life Preserver."
The content may be an exclusive innovative on the basic things......
java training in navalur
selenium training in navalur
Great share! Thanks for the information. Keep going!
Post a Comment