And by steps, I don’t mean “Open the point of sale, sell something, pay with a credit card, and see the error.” That’s not good enough. You need to give every single action taken, down to the mouse clicks and keystrokes. The more detail in the steps, the better. If you are a QA person and the developer says, “There are too many detailed steps!”, pat yourself on the back and tell him to suck it up. You’ve done your job well.
Actual vs. expected behavior
Every bug occurs because one thing is supposed to happen but something else happens instead. Sometimes it is the wrong output. Sometimes it’s a crash. Whatever it is, a good bug report will define what should happen when the steps are followed and then very clearly detail what actually happens instead. You can’t fix incorrect behavior if you don’t know what the correct behavior is. Every bug report should make that very clear.
Context and system details
No bug lives in a vacuum. Provide relevant context or system information that might be helpful. Include information on how the bug is impacting the customer, operating systems used, browser types, a query to run on the data to see the issue, etc. Include anything that might help explain the problem and its impact.
