Top Tools - Screen Capture tools
The primary deliverable for many testers are bug reports. A treatise on what makes a good bug report is a post in and of itself, so i won't drill into that part (now), but will say that it's true that a picture says a thousand words. I've seen many bug reports with very little information get tossed around in triage meetings for weeks without resolution, because the tester didn't do a great job explaining the issue. I've also seen many bug reports with tons of information get tossed around in triage meetings for weeks without solution, because the triage team didn't want to wade through reams of complicated explanations.
Enter the screen capture tool - It's amazing how much a screenshot can help move a bug along. Everyone instantly grasps the problem without having to figure out what you are trying to say, and can make decisions quickly, plus you don't have to type so much.
So what are good tools to use for this? For me I look for a few different features:
- Easy to invoke
- Provides basic cropping
- Provides ability to highlight specific areas
- Integrates well with my bug reporting tool
My current screen capture tool of choice comes from the reporting tool we use, FogBugz Screenshot. It sits in my system tray, a single click on it takes a screenshot that i can then crop, add highlighting to, and then either append to an existing bug, or create a new bug.
Check your current bug system and see if there is a similar facility, you'd be suprised how many of them actually provide something.
If your bug system doesn't there still are lots of other great screen capture tools out there. I've been using the Snipping tool in Windows 7 a lot recently as well. This lifehacker post has a list of a bunch of other great ones.
If you want to get really sophisticated you can grab one that actual makes recordings for complicated scenarios, like this tool.
Obviously if you are working on something that doesn't have a UI to take a screenshot of, then this isn't specifically helpful, but your takeaway should be about determining the best way to get your bug across visually. We have an image transcoding service without a UI, but providing before and after images as well as expected image helps get the point across alot better than a few lines from an error log.