Best guidelines to create images for bug reports in big testing team?

Question

Which set of guidelines should be used in a big testing team to reduce differences in created screenshots. Devs and PMs could go crazy from different ways five testers create screenshots and highlight them. As I see it would be great to have short guidelines for all testers and there are three of them till now:

• color usage in images
• tools used to create screenshots
• naming of images

Color usage in images

Orange color for highlighting errors (personally don't like red cause I want to have good relations with Devs. See also Teachers should stop using red pens to mark homework), green for highlighting correct behaviour and for short comments what actually should be done to fix the bug.

Tools used to create screenshots

To reduce differences in style and avoid usage of old, inconvenient tools (e.g. Paint). And to use tools created especially for this purpose (e.g. TechSmith's Jing or SnagIt)

Naming of images

Timestamp followed by clear description what is going wrong. Like in TechSmith tool:

2015-10-14_1531_[description of the image clear to human being]

The image should be mentioned by name in bug description or in comments to bug report (Otherwise why do we need this image and why should I or Dev, PM check attachments if it's not mentioned in bug-report?)

Any other suggestions? Is there anything wrong in my idea?

EDIT:

• added several tools for screenshots and image edition as suggested by @Dhiman

EDIT (2015/11/11):

As of now we don't use timestamp in image names (it's enough of create time in image-file attributes), but we added release number and server to the name. E.g.:

58.1.3_[Test_server_name]_[Image_name_clear_to_human].png

It's very usefull for regression testing you see the configuration where the problem was found.

Answer 1

I think your suggestions are very good, it is always good to have clear guidelines. Though they should not be set in stone and should be used as a guideline and not as a rule.

Full-screen

In order to reproduce the issue I want as much information as possible. A screenshot can tell a thousand words. Some people make only a screenshot of the part they think is important, but I always want a full desktop screenshot.

Full-screen images include the time, the URL and or other screens and selections the user might have. This info is often key in fast reproduction of the issue. This will help developers and testers when re-producing or re-testing.

Answer 2

Images for bug reports should:

• contain all the information needed. So for browser screenshots use the whole browser window so people can see the browser, browser version and any toolbars that reflect installed tools and any footer toolbars that show info.

• not contain irrelevant information. I am not a fan of the whole desktop screenshot as it includes too much non-relevant, distracting and possibly even personal, information. Also it often means you then have to zoom in to see the actual window and issue.

• be taken in a format that allows the image to be shown embedded into your ticket tracking system if you are using one.

• show the flow that leads to the error. In this case I expand 'screenshot' to include using a movie and I use QuickTime (OSX) to do screen recordings. This can be incredibly helpful when bugs are hard to find and reproduce. For movies you may want to limit yourself to a part of a window in order to save space and reduce file size. Remember that a 9"x9" movie is nine times bigger than a 3"x3" (9*9=81 and 3*3=9)

• be annotated with additional text to help indicate the problem. Commonly done with red to circle items or write comments. This can be done on top if images using free or low cost tools such as http://www.quickpicturetools.com/en/add_text/ For example:

• should contain date in the filename format when available by default. Many screensavers use a data and time in the filename. Make this a required procedure. This addresses one of the main useful things of a full screenshot. Also http://www.allthingsquality.com/2010/04/picture-is-not-worth-thousand-words.html highlights the following:

• A picture doesn't explain how we got there

• A picture by itself doesn't explain what is right, and what is wrong
• A picture doesn't explain the expected result
• A picture doesn't help when searching

So make sure you supplement a picture with such context.

Personally I do NOT pay attention to date stamp and screenshot file name description. I put all that meta-data into the bug tracking system that includes the screenshot, e.g. Trello, Jira, Pivotal Tracker, etc.

Answer 3

I will answer/go through your points one by one and will try to add some valuable information in addition to your useful & precised description.

Color usage in images: Highlighting becomes critically important when creating bugs related to GUI. Regarding the color, we have been using Red (R =255, G=B=0) and Blue (R=G=0, B=255) color only for highlighting in our team (via SnagIt) from last couple of years and didn't faced any issue with any developers. I have gone through the posted article and will say, If highlighting bugs with red color can lead to team issues then creating bugs is more offensive then that.

So, you can use Red color without any issue as this is part of job which team should understand (I don't mind your Orange color idea too), but Red color is more eye catching. We have defined two colors because sometimes the area which you want to highlight already have either same background or border, which makes highlighting not usable. So, define two color for highlighting.

Tools used to create screenshots: I already mentioned that SnagIt is most widely used and feature enriched tool for capturing and editing images for creating bugs, User Guide, Release Notes etc. It also provides 'Auto Scroll' option which is very usable and time saving when you need to take screen shot of complete page, else you will end up taking multiple shots and then adding them to one. Can't tell about Jing as I haven't used it.

Note the first two in the list here (Snipping Tool and FastStone Capture) are only for Windows.
No OSX or Linux version.

Naming of images: What we are using this regard is very much similar to your defined guideline i.e. the DateTimestamp_PageName_SectionName(if multiple sections/tabs are there on page)_DefectedFunctionality/Feature.

In addition all this, I completely agree to 'Niels van Reijmersdal' idea of Full Desktop capture and just adding to it; I have seen that full screen captures also helps in determining the path of that particular page which contains error e.g. if your application maintains/displays the navigation path (Breadcrumbs) then that path is quite important for developers (especially new developer in big application) as it will easily leads them to that page without help of any other team member.

Then, you need to define the usage of

• Text Boxes (their border, fill color, Easily readable Font & Font size)
• Arrows, Pointers, Lines (Color and Width)
• SnagIt Stamps (very useful for defining steps in images)

I will say keep the guidelines and all these settings simple, little flexible & light. In my last project we have created a client shared document for these guidelines (not for the purpose of bug reporting specifically, but mainly for User documentation purpose) and have made it part of Induction process for new QAs.

Answer 4

At our company we use screenshots quite rarly for bug reports, mostly only to show visual errors as a screen can tell more than 1000 words. To highlight we normally use green for correct behavior and a blue (or torquise) to highlight non-correct behavior - this comes due two points:

1. Better contrast to the GUI
2. Avoiding red/green blindness problems

But of course an strong description of the problem to every screenshot is a must. The screenshot is only an addition to the wording of the bug report.

In more than 95% our tests / bug reports we use the video tool HP Screen Recorder (as we work with HP ALM anyway) and these videos can be visited frame by frame so you can see every single step e.g. when the GUI is build.

Even it's a bit offtopic: Guidelines for our video snaps are also include

• Full Screen (to see other open programs, URLS etc.)
• Showing the "Info" screen with version number you made the video
• Showing some base data (if relevant for the bug, maybe a calculation)
• Show all steps you do until the error occurs
• Adding textboxes / errors / highlighting frames to the videos to give information to the viewer like "I'm pressing F12 now"

This helps the developers a lot to identify the causes of errors when they are are not straight-forward caused by the point where they occured but because of "failures on the way" or because of bad base information the tester isn't aware of - and so it may not be in the bug reports. And this is often the case because the quality of some of our bug reports come from the persons who work with the software in the end and who are not trained in how to write good bug reports.