Bugs Reports and Feature Requests

 

Introduction

During testing phases of a product, bug reports and feature requests are two of the most commonly used forms for providing information back to the development team.

 

Bug Reports

Bugs are the slang term for problems in software and electronics. These problems can exist for a number of reasons, most often one of the following.

In most cases, a bug can be indicated when the thing that seems to make the most possible sense either didn't work or provided incorrect results. Whenever you encounter a problem where a certain type of action was supposed to occur and it didn't, or whenever a completely different action occurred than what was normally expected, a bug report is the most appropriate call.

For example, if you select Print from the menu and no hint of printing takes place, you can almost guarantee by intuition that you have encountered a bug.

 

Feature Requests

Contrarily to the term 'bug', which typically refers to a feature or component that has already been implemented and is having trouble doing what it is written to do, a feature request might be something you use as more of a catch-all for anything that has not yet been added or for which a change could be suggested.

 

Features and Product Improvement

On many occasions, the exact idea of a feature request is to express something to the overall wish list of capabilities the product should receive as its stature improves. There is virtually no limit to improvements that can be requested except that each of those requests be directly related to the product being described.

 

Features and Incomplete Design

Not every feature request is daisies and buttercups, because sometimes, feature requests can also be used to report problems, too.

To determine whether your issue is a feature request, first eliminate the possibility of it being a bug. This is not always the easiest decision to make because a feature request might have some traits of a� bug, especially in times that an absence of functionality keeps you from getting your job done. The one aspect making a feature different from a bug is measured along the development path.

Computer and software logic is very specific in that the only functionality a digital system ever supports is that which has been explicitly defined for the product. Therefore, if little or no effort has yet been put into a desired feature, that actual feature is not expected to perform its full work until it has been defined, tested, and released.

One example of this decision might be shown in a car without breaks. As a driver, you are going to get in big trouble without them, but if there had never been any plans to include brakes into the design and somehow the car had reached public testing, the request for brakes would be handled as a feature request instead of a bug report.

 

Why the Difference?

At this stage of the game, bug reports and feature requests are really only separated by a semantical difference. In most cases, if you mistakenly report a bug as a feature request or visa-versa, no harm is done in any way, and those reports can be freely moved from one category to the other by the project manager if needed.

The real difference between these two types of public input comes in how the resulting work is planned, based upon the input that has been received. The following outline details our general planning strategy when improving an application for testing.