JoeBork's Weblog

Breaking software in new and interesting ways

Three quick tips for reporting GUI bugs

This entry doesn't have any deep insights into software testing in general (or even GUI testing specifically), but I'd like to share some simple tips that can come in handy if you're reporting a GUI bug.  There's nothing particularly special about them but I'm always surprised at how many people don't know them, and they're all easy to use.

  1. (Almost) Never send a capture of the entire screen

It's pretty well known in Windows that the “PrtScn” key will capture the current screen as an image on the clipboard.  For a lot of UI issues, it's incredibly helpful to know exactly what someone is seeing on their screen rather than to try and have them describe it in detail.  Since it's common to have systems running in pretty high resolutions these days (1280x1024 or higher, for example) a full-screen capture produces a very large image, both in terms of resolution and in terms of the size of the saved image.

Instead of using “PrtScn”, use “Alt+PrtScn” instead.  This will capture only the window that currently has focus instead of the entire screen.  Of course, if you're taking a capture of a maximized window, or if you need to capture overlapping windows, this won't help you.  In general, try to capture the smallest amount of the screen that is helpful in describing the problem.  Windows still comes with Paint (or “Start | Run | pbrush.exe” as I like to think of it), and Paint has a very simplistic cropping tool.

  1. Save screen captures in PNG format, not in BMP or JPG format

Since at least Windows 2000, Paint has had the ability to save files in PNG format.  This is the best image format for sending screen captures for two reasons:  It is compressed, unlike BMP (which can result in huge file sizes for high resolution displays in 24- or 32-bit color depths), and it's compression algorithm is lossless.  The latter means that PNG files will generally be larger than the corresponding JPG file, but JPG compression is lossy, and for some kinds of UI bugs that deal with pixel-level details, the compression artifacts introduced by the JPG compression can do more harm than good in trying to determine the root cause of the bug.

  1. Send the message text of an error dialog instead of a screen capture

This is the least-well-known of the three tips.  For almost all of the error dialogs that Windows applications generate, it's very simple to capture the text of the dialog in lieu of an image of the dialog window.  It's very simple: when the dialog box has focus, press Ctrl+C to copy the text of the dialog to the clipboard.  Windows even formats the text nicely, so you'll get something that looks like this when you paste:

---------------------------
Paint
---------------------------
Save changes to untitled?
---------------------------
Yes   No   Cancel  
---------------------------

Being able to send the actual text of the error dialog has a lot of advantages:  It avoids transcription errors (particularly helpful when reporting some arcane error messages with hex error codes or exception typenames), it's even smaller than the PNG image of the dialog would be, and it makes it much simpler to search for other reported bugs with similar error messages. 

So there you go.  No great philosophical discussions, but at least you have a few concrete, practical tips.  If you're a beta tester and you keep these things in mind when reporting bugs (either via the public newsgroups or Betaplace), I guarantee that the people who will be following up on your bug reports will appreciate it.

Published Friday, March 05, 2004 8:16 PM by joebork
Filed under:
Anonymous comments are disabled

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker