Classifying bugs is a tricky business
Generate an AI Snapshot to get a quick, structured summary of this paper.
A concise AI-generated summary of the paper will appear here once you click Generate AI Snapshot.
TL;DR
In this paper, the authors compare several different methods of bug classification currently being used in software engineering projects, and show their weaknesses; while their method of using intended programming plans is not without problems, it is argued that it presents a better alternative than the other methods currently being employed.
Abstract
Abstract : In order to build a computer-based programming tutor for novice programmers, it was necessary to first classify the bugs found in their programs on the basis of type and frequency. However, the enterprise of classification turns out to be a complicated process. While one may want to be able to simply use features in the program itself as the basis for the classification, it turns out that such a scheme will result in classifications that seem to miss the mark, i.e., the classifications will not tell you what misconception the programmer was operating under which caused the bug. To remedy this situation the authors that the programming plans that the programmer intended to use should be the basis for a classification scheme. Thus, a bug classification must take the programmer directly into account. In this paper, they compare several different methods of bug classification currently being used in software engineering projects, and show their weaknesses; while their method of using intended programming plans is not without problems, it is argued that it presents a better alternative than the other methods currently being employed. (Author)
