The First Step Isn t Finding, It s Tracking

The First Step Isn't Finding, It's Tracking

Most people mistakenly believe that the primary job of the quality assurance manager is to find software bugs. However, before a manager can find the bugs, he must also have a system in place to trace the bugs when found and track them until they are fixed. Unless you have a tracking system in place, a development team will spin its wheels trying to fix errors while missing new ones.

Why is tracking so important? Obviously, bug tracking allows you to log bugs as you find them so they are not forgotten and can be fixed. The real power in tracking comes when you use the data collected to form patterns and make some simple assumptions on where they might occur in the future. You can also identify programmers who are prone to making coding mistakes and those who ignore fixing requests.

Charts and graphs can be made showing combinations of data to your advantage. Unless you have a way to collect and store data, you will be missing out on many time-saving clues. For example, what if you wanted to know how many bugs were being found each month in a given area (Figure 4.7.1)?

Figure 4.7.1: New bugs found each month in each game development area.

By using time as your x-axis, you can rapidly see areas that might raise alarms. In this example, the number of bugs found in the 3D engine keeps growing. The manager needs to determine why, and whether more resources are needed. On the other hand, there are few bugs found in the Design area at the end of the chart. Maybe the team has solved nearly all of the design issues, but perhaps more attention needs to be focused in that area so it does not become neglected.

Without using a report of some type, this data is hard to see. You can also track your personnel to make sure they are fulfilling their responsibilities to correct errors as they are found (Figure 4.7.2).

Figure 4.7.2: Open bugs at the end of each month by developer.

In June, Monica and Louis are having trouble correcting their bugs at the end of the month. The manager needs to know if this is because of lack of motivation on the developer's part or some other reason. We can also see that Louis consistently closes out his bugs each month. Charts and reports make information like this readily available. Other reports can be generated to show average length of time a bug stays open, developer productivity, and success and failure rates of test cases. All this requires is a bug-tracking database.