Kids love bugs, and some kids even collect bugs and keep them in precious “kill jars.” Over a period of time, bug collectors can amass a large number of different species of bugs. Some kids study the bugs they collected and label them based on such characteristics as shape, size, color, number of legs, whether it can fly, and so on. The bugs may be valued differently depending upon how rare they are or how difficult they are to catch. The collection may have some duplicate bugs. But duplicates are rarely identical, as characteristics such as appearance and size can differ widely.

But we software developers do not like bugs. We hope to have none in our software, and when they are found, we squash them! Unfortunately, squashing bugs, or more politely, responding to software change requests, is rarely easy. Developers have to study the information about the bug in detail, conduct a thorough investigation on how to resolve the bug, examine its side effects, and eventually decide on and take a course of action. This is a difficult task because, like earthly bugs, software bugs differ widely. Often software bugs that are collected in bug databases of projects are studied in isolation because they are different from the other bugs in their effects on the software system, their cause and location, and their severity. Over time, a project will accumulate duplicate bugs, just as a live-bug collector may have multiple bugs of the same species. And finally, nearly every project knows about more bug reports than it can fix, just as there are too many live bugs to be collected by a single person.

So the study of software bugs is a valuable pastime. The starting point for the study of software bugs is the information filed in bug reports by those who report them. In this chapter, we discuss the characteristics of good bug reports and implications for the practice of collecting bug reports.