Difference between revisions of "How to Fill Out Bug Reports"

From Wasya Wiki
Jump to: navigation, search
(Created page with "In software engineering, bugs are important! And it is even more important to fix them. Reporting bugs correctly gets you half-way to getting them fixed, which in turn gets yo...")
 
 
(One intermediate revision by the same user not shown)
Line 4: Line 4:
  
 
Alternatively, a non-trivial bug report, instread of describing a piece of functionality in a simple English sentence, should instead consist of three parts:
 
Alternatively, a non-trivial bug report, instread of describing a piece of functionality in a simple English sentence, should instead consist of three parts:
- the location of the bug. A screenshot, or a URL, are usually good.
+
* the location of the bug. A screenshot, or a URL, are usually good.
- the operation that you are performing. What are you clicking? Or, how are you interacting with the interface?
+
* the operation that you are performing. What are you clicking? Or, how are you interacting with the interface?
- what is the observed behavior? This is the bug.
+
* what is the observed behavior? This is the bug.
- what is the expected behavior? This is the spec.
+
* what is the expected behavior? This is the spec.

Latest revision as of 20:17, 18 May 2014

In software engineering, bugs are important! And it is even more important to fix them. Reporting bugs correctly gets you half-way to getting them fixed, which in turn gets you closer and closer to the eventual goal of happiness and prosperity for all.

When reporting bugs, please write in full, grammatically correct English sentences. Furthermore, the bug report should express what *should* be there, not describe the error that needs fixing. Bug reports are declarative (they describe functionality) and ideally they can be used as specs as well - that is, they should in fact describe functionality.

Alternatively, a non-trivial bug report, instread of describing a piece of functionality in a simple English sentence, should instead consist of three parts:

  • the location of the bug. A screenshot, or a URL, are usually good.
  • the operation that you are performing. What are you clicking? Or, how are you interacting with the interface?
  • what is the observed behavior? This is the bug.
  • what is the expected behavior? This is the spec.