In order to have a defect resolved efficiently, there are some guidelines for creating reports that are easy for developers to interpret and follow.  Bear in mind that your reports should contain information needed by developers (to fix the bug), managers (to assess risk and prioritize work) and fellow testers (to verify fixes and find out if known defects may be the source of current problems). 

1.                  Document immediately – modifications/details can always be added later

2.                  Create a title concisely describing the problem – NOT the solution.  You wouldn’t tell a doctor what medication to prescribe, rather you would tell them your symptoms.

3.                  Specify module affected – metrics based on this info can help identify areas in which to target future testing efforts

4.                  Assign priority according to agreed upon definitions

5.                  Explicitly list steps necessary to recreate – this will help developers as well as testers verifying the fix

6.                  Cite requirement – ALL defects should map to baselined requirements.  If there’s no requirement, it’s likely a change request and should be handled as such.

7.                  Include version number and environment(s) where problem occurs

8.                  Seeing is believing – attach stack trace, screenshot and complete text of error message where appropriate.

9.                  If defect is intermittent, describe frequency and as many details as possible (application state, time of day, path taken, username, etc.)

10.              Identify any resulting data corruption that will require clean up

11.              Workaround(s) – carefully document steps

Referencing a requirement number (and not beginning work on defects entered by clients until there is an associated requirement) helps prevent scope creep.  This also prevents users from later defecting the “fix” again because they changed their minds – again.

It is not enough to describe what you see.  A developer might retrace your steps, see the exact same thing and think it’s fine.  If you do not describe what you expected to see, then you have not described the problem.  Referencing a requirement may not be enough.

Correctly determining priority and being aware of known workarounds are important for managers and clients in deciding when and how to handle fixes.  Workarounds also minimize the creation of bad data before fixes are implemented.