4.3. Flexible Reporting: Beginning to Construct a Database
You could implement every piece of advice in the previous section in a bug reporting system that relies on email or a flat file. I have seen projects that use spreadsheets or word processors to track bugs, but the reporting options were sparse, limited to little more than a printout of the worksheet or document. (Spreadsheets can summarize and graph data, as discussed later in this chapter, but with poor text reporting capabilities. Word processors have good text formatting, but poor analysis and graphical abilities.) To store, manipulate, search, analyze, and report large volumes of data flexibly, you need a database.
There are certainly many options for commercial and freeware bug tracking databases you could buy. However, many companies do build their own. Therefore, this section explains how to build a bug tracking database using what we've discussed so far. Later sections of this chapter build on this foundation to enhance the database's capabilities. I used Microsoft Access for the database shown here, but you can use StarOffice, FileMaker, Oracle, or any other relational database application. In the course of these discussions, you'll see not only how to build a bug tracking database, but what fields you should look for in a commercial bug tracking system if you decide to buy one.
Minimally, a bug tracking database stores failure descriptions—summary, steps to reproduce, and isolation—together with identifying information ...