Issue Tracker - Githubissues

From the canvas page for "Testing" A “finding” can be a bug, something that is unclear, inconsistencies, features that appear to be unimplemented, or any other aspect of the system that affects usability for the purpose for which it is being built. For example, you may wish to comment on installation, the documentation (including on-line “help”), the user interface, performance, misbehavior of various kinds of inputs or user actions, scalability, etc. This list of areas is a guide; you may add or change the areas if they seem more appropriate for the project you are testing.

Each finding should contain at least four things:

a one-line summary of the problem (typically in a “Summary” field) a description of the problem (typically in a “Description” field) the severity of the problem (typically in a “Severity” field) any suggestions or comments (also typically in a “Description” field) Include sufficient information on how to reproduce the bug, to help the other team in debugging, and whenever possible/applicable, please include a stack trace in the description. Severity levels may vary from one bug tracker to another. Typical severity levels include: a blocker is a bug that the product cannot possibly ship with; critical through trivial are gradually lower levels of severity; and enhancement is for a request for a new feature. Remember that you can also enter bugs for design or specification problems.

Suggestions are for conveying information beyond the description that may not be immediately apparent to someone reading the document. For example, if you suspect that a particular problem is the result of a race condition, you would put that hypothesis in the suggestions section of the finding. Your suggestions can be empty and should not restate the obvious. For example, if you report that a feature is unimplemented, please don’t bother suggesting “Implement the feature.”

hbrooks3 / bph-front-end

Issue Tracker #9