Reporting bugs

A good tester makes it easy for the developers to identify and fix bugs. These guidelines are designed to assist you in becoming a good tester.

Rules for posting bugs:

All bugs or error reports must adhere to the following rules:

1. Apply the bug label when posting a new Issue on GitHub for the bug or error.
2. Version of the software (Can get this using --v switch on the command line for SMP projects)
3. Steps for Reproduction: Specify all the steps you took from the start up until the point you got the error.
4. Expected Results: State what you were expecting to happen. This tells developers why you are classifying this the issue as a bug. If you don't do this, developers may not see why this is a bug. It's like going to a computer store and stating that you got a "Black Galaxy Tablet". " So what!? ", they'll say. " You got black tablet, what do you want us to do ". You then show them the receipt which says that you ordered a " white iPad " instead. They say " Ah, we see. Sorry, we will get the iPad for you right away ". Don't assume developers to remember all details about the project and instantly pick up what you are trying to say. Developers normally work on multiple projects, from Java applications to web platforms and write a lot of code and can't remember all details.
5. Actual Results: State the results you actually got. If you don't do this, developers don't know what you got.

Take a look at this issue I created as examples: https://github.com/starscriber/coding-standards/issues/1 and https://github.com/starscriber/coding-standards/issues/2.

Rule for Closing Bugs:

The only person who can close a bug is the one who opened it. Anyone can resolve the bug, but the person who submitted the bug request is the only one who can close it.

Do developers need to fix every bug:

Absolutely not. If the "bug" is stupid because the tester was trying to run the application in Windows instead of Linux, using OpenJDK v1.0 instead of Java 7, why fix it. If this is the case, please do the following two things:

1. Apply the label "Won't Fix" to the Issue.
2. Comment: "Won't Fix". This will identify the developer who's very nicely flipping the bird.

Don't close the bug issue after applying "Won't Fix"

Don't be crazy with Bug Reporting:

The reason we are not using JIRA for internal bug reporting is that it is insane. It has fields like 'Track Bug Progress', 'Number of People working on the bug and the %age of time each spent on trying to fix it', 'the day Bob started fixing the bug, the holidays he took', etc. Please keep it simple. If you would like to attach a new label like 'Resolved' etc. go ahead, but keep it simple.