Bugtracking Software, Quality Assurance, and Regression Testing

Software development has a number of best case practices, including code re-use, being able to document code, and being able to read code in the future is also important. (One way to describe the difference between Python and Perl as programming languages is that they're functionally equivalent, but that you'll still be able to read Python code 6 months after it was written.)

However, no matter what your best practices are, you're going to have software bugs. Finding, fixing and solving software bugs is an important part of the development cycle, and involves quality assurance testers, customers and your development staff, all working with slightly different agendas, and likely communications issues. This is where bugtracking software comes in.

Bugtracking is the fine art of triaging problems in code. Triage is a term borrowed from medical parlance where doctors were overwhelmed with patients and had to choose which ones to work on, based on criticality of the disease, likelihood of success in fixing the condition with the resources available, and how likely the condition was to come up again.

Interestingly enough, with bugtracking methodologies, there is a similar hierarchy of information. Criticality of the bug means that it happens frequently, or when it happens at all, completely unacceptable results come from it. The ability to fix the bug depends on how accurate the reports are when submitted by a user; whether the bug is repeatable without effort, or only appears randomly when someone is doing something with the software that no sensible user would do. Likewise, being able to isolate specific versions of the software and specific issues is a great aid in helping the developers go through the source code and fix the problem. (This is where the quip about Python comes into play. Code that can be read after it's been written and is clearly documented, is much easier to bounds check and version check than code that was dashed off in a hurry, was made to work, and then moved on from.)

Bugtracking software is usually database driven with tester (and sometimes user) input points, where they can submit what they were doing, the configuration of their testing rig or production computer, and any other data they think is pertinent. Important categories are "what type of bug" is the problem; this helps assign the bug to the right developer for evaluation and whether or not it gets fixed.

Note that it is acceptable and common practice, to decide that a bug is livable as is. This usually comes about because of a step called regression. If you fix a bug, and turn it in, there's no guarantee, especially with extensively cross linked code, that by fixing a bug you won't introduce another bug that's even worse. This is one reason why a lot of bugtracking software is primarily used to say "This is a bug we can live with..." particularly for incidents that aren't easy to reproduce, or won't be common in actual use of the software.

Source:http://ezinearticles.com/?Bugtracking-Software,-Quality-Assurance,-and-Regression-Testing&id=2383299
Author:http://EzineArticles.com/?expert=Jimmy_Drago