Because it's such a good post, I'm stealing Anne-Marie Charrett's post from yesterday on "Do your bugs only glow when its dark?" In the post she outlines some guidelines she uses to report bugs when doing offsite exploratory testing:

• Provide the time it takes you to write up the defects in your estimate


• Get agreement on the level of detail for defect reports


• Write up the bugs as you find them, don't let them queue up


• Encourage customers to use a defect tracking tool

Read her full post for the details!

Defect databases get big quick. Even on a well coded, well run project, if the development team is firing on all pistons a backlog of possible issues, bugs, and feature requests will build up. Over time, tickets can get stale. They become less relavent, are fixed indirectly, or change in priority/severity. From time to time, get in there and clean em up!

This activity can be rewarding on multiple levels. First, if you just go in and clean our your personal backlog (the tickets in your queue), you get a better idea of the work that's really on your plate. This both reduces the burden you might feel (like when you have an empty inbox), and also helps you prioritize the work better. Second, if you clean up, update, or refresh all the tickets you've entered (possibly hitting other people's backlogs), you give that same small charge to the entire project team. If everyone does it regularly, the database of tickets remains clean and relavent.

When you're testing a web application and you find an error, save the HTML. When you writeup the defect report, a lot of times it can be helfpul if you paste in the HTML for the page. If it's a lot of code, just save it off and attach it as a file. There's often a lot of informaiton found in the HTML that isn't rendered on the screen.

When reporting issues where you don't know the root cause, be sure you include the following information (if applicable):

• screen shots


• log files (local and server if you can get them)


• machine stats (CPU usage, memory usage, disk, etc...)


• what was happening:
  
  
  
  • What were you doing (steps, activities, etc...)?
  
  
  • What else might have been going on at the same time (volume, batch jobs, etc...)?
  
  
  • What else was doing on right before the error occurred?
  
  
  
  


• copies of the configuration files at the time, or a summary of key configuration settings

At CAST 2008, during a conversation on intermittent bugs, Jeff Fry provided the following tips to help isolate what's going on:

• Try varying your inputs


• Switch browsers


• Very concurrency and load


• Change your speed of execution


• Change your perspective (six thinking hats)


• Change the platform you're running on


• Try using a recording tool or additional monitoring tools