QAInsight.net, QABlog.com, QABlog.net
Brent Strange's thoughts on Software Quality Assurance and technology

 
Wednesday, January 04, 2006
 
 

The good and bad of defect screenshots

 
 

Is your defect database full of screenshot/images? Do you or your team ALWAYS attach screenshots? Screenshots in defects have a good and a bad side. Here's my take on it:

The Bad

  • Images can make a monster sized database. A majority of testers aren't equipped with an image capture tool that provides lower quality and smaller sized images so they default to the good ol' screen capture and paste that into Microsoft Paint. Using MS Paint, a 800x600 screenshot saves a BMP at 1.35 MB and a JPG at 123 KB (A JPG at 25% quality in Photoshop = 92 KB). MS Paint defaults it's save extension to BMP and a lot of people don't know much about image compression so they'll leave it at BMP. Let's crunch the numbers... (1 project with 250 defects containing screenshots) x (1.35 MB) = 337.5 MB of images. That's a lot of MB for ONE project. Multiply that by 30 projects a year (Corillian probably does double that EASY) equates to over 1 Gig of images! Get my point?
  • Defect screenshots can promote laziness. You know what I'm talking about, that defect that you open that says "See attached screenshot" and little to nothing else. See what in the attached screenshot? How good the GUI looks when saved as a BMP? :) This can be a serious problem with new testers and will cause a lot of back and forth between tester and developer as the real details are ironed out. Obviously this is very inefficient when the tester could have prevented the confusion by wrapping the image with descriptive text about the defect.
  • Screenshots aren't searchable. If you can't find a defect from keyword(s) (for example: a JavaScript error) you are going to have a serious problem with defect duplication when the project defect list gets long or if you have more than 2 testers on the team.

The Good

  • Images can be easier to comprehend (if the defect reader knows exactly what they are looking for in the image).
  • Images provide evidence. When the defect can't be reproduced, you have that screenshot to go back on and then you don't feel like you were crazy on crack at the time because the screenshot says so.

Screenshot advice for testers and team leads

  • Only use screenshots when the error is so technically confusing to describe that a screenshot will SUPPORT the description. Take the time to describe the problem, document the error text and provide a good description of steps to reproduce. By providing these things along with the screenshot you now have a defect that is highly searchable (preventing duplication) and has a supplemental image in case the text description didn't cut it.
  • Testers: If you're going to take a screenshot save it as a JGP or GIF not BMP. Leads: If possible, empower your testers with an image capturing tool that creates compressed images.