Screenshots: A Primer

Screenshots are the QAer’s best friend, gentle reader. Appended to a defect report or printed on a color plotter at 20″ by 30″ so you can wave them two-handedly in front of the developer, they can prove conclusively that something very wrong happened with the application. Because otherwise the developers will fix something and claim it was never broken in the first place, or the humidity within the office will change, altering the flow of electrons through the network cable, producing different results when you try to recreate it, or something. It’s always something.

So, at any rate, a good screenshot adds a lot of value to a defect report or other communication.

As you might know, gentle reader, I used to be a technical writer before I gave up trying to explain the inexplicable and decided to seek and destroy it instead. So I have some advice for taking screenshots effectively. Most of the advice that follows talks in terms of Windows-based computers, but if you’re in QA, you should be smart enough to apply the lessons to other platforms.

First off, you need a program that can handle bitmap images, such as Microsoft Paint (standard with a Windows install), Microsoft Word (if you have Microsoft Office installed), or a custom graphics program. I’ve always been happy with Paint Shop Pro because it’s under $100 and I’ve used it for almost a decade. However, Photoshop or what have you will work as well.

Next, there are two ways to take a screenshot. You can simply press the Print Screen key, which takes an image of the entire desktop including taskbar and whatever bits of your wallpaper might display behind the application you’re testing. This is typically too much information, so you’ll only use it occasionally. I mean, here’s a busy screenshot of my whole desktop, including windows open beneath the application I want to call out:

Bad screenshot
Click for full size.
Attach that to a defect report, and you’ll overwhelm a poor, simple developer.Now, if you press the ALT key and the Print Screen key, Windows will take a screenshot of just the active window. Like this:
Proper screenshot
Click for full size.
Now, be careful if you’ve got a floating window that’s not maximized and it’s tucked under the taskbar, as this will capture the taskbar, too:
Hey, that's the taskbar!
Click for full size.
That’s just poor craftsmanship.Now, keep aware of the various and sundry things that pop unbidden onto your screen while you’re taking screenshots. Some applications grab focus or display notifications in the corner of your screen on events, and if you get any of those things, retake the screenshot. Geez, this particular screenshot appeared in the June issue (PDF at the link) of Software Test & Performance magazine. The QA guy himself and any editors at the magazine just let this go. In the magazine itself, you can even make out who sent him that offending e-mail:
Click for full size.
Now, you’ve got the screenshot and you’ve pasted it into your graphics package. It’s okay to use some of the graphics tools within the graphics program to highlight or add explanation:
Isolating items of interest
Click for full size.
Additionally, you can judiciously use the cropping feature of your graphics package to bring the issues to prominence.Now, remember I said there was one reason to do a Print Screen shot that doesn’t just capture the active window? If you’re showing a modal dialog box, such as a message box or other sub-window functionality, ALT+Print Screen will only capture the modal dialog box and not the underlying state of the application. Like this:

Modal dialog, isolated
That doesn’t tell the developers much, and they like it that way, since it presents less challenge by their subatomic consciences in rejecting the defect.Instead, you should take a full desktop screenshot and then crop it down to just the application you’re testing:
The modal screenshot
Click for full size.
That way, you can show more about the state of the application behind whatever modal dialog you show.Now, about saving those screenshots. Hopefully, you’ve got a real graphics package and can save the images as either a JPG or a GIF. This makes the image easy to review in other graphics programs or in Web browsers if your defect tracker is Web-based. Of course, if you don’t have a graphics package, you can save the image within a Microsoft Word document. You want to avoid proprietary image formats (such as Paint Shop Pro images with .psp extensions) or more esoteric image formats (TIFF or whatnot) because they will require image programs to review. You probably want to avoid bitmaps or Windows file formats as they can be large in size.Now you can attach your stunning, hard-hitting evidence of application failure to your defect report. Not that it’s going to matter one difference to your technical staff; they will receive the report, ignore the image, bang randomly on the keys while making monkey sounds, and when that fails to cause the problem to occur, will mark this issue as not reproducible.

But you have proof. And you’re not crazy.

(As a footnote, if you’re testing on a Macintosh, you can do a screengrab in different ways recounted here.)

Comments are closed.

wordpress visitors