8

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.

  • 1
    For your tools point, I would like to add that you should go for TechSmith's 'SnagIt' tool for capturing screens shots. Me and my team too uses this tool for the capturing bug and user documentation screen shots and I love this tool and its very easy, feature rich tool. I didn't want to post it as an answer because it may start a discussion. – Dhiman Oct 15 '15 at 13:50
  • 1
    " Devs and PMs could go crazy from different ways five testers create screenshots and highlight them." I guess I haven't ever seen this become a real problem. As long as the images can easily be viewed and understood, I would avoid such "standards" as unnecessary. You do have a real bug tracking system, right? You aren't relying solely on pictures? – Joe Strazzere Oct 15 '15 at 16:31
  • @JoeStrazzere, we use HP ALM 12.20. And there are about 3500+ bugs in system, the problem comes when a bug has a long history and 3+ attachments made at different time with names like "bug308", "pic001" etc. and there is no text in description like "see attachment bug308", just may be "check the attachment", but which one? – Ivan Gerasimenko Oct 16 '15 at 7:46
7

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.

  • This point is extrimely important when there are a lot of newcomers in testing team: they may not know what is actually important on the screen – Ivan Gerasimenko Oct 15 '15 at 9:39
  • +1 for the full desktop screenshot. I've worked on many apps where a widget or UI block might display on several different pages, or user may have followed different paths to reach it. Full screenshot includes breadcrumbs and other vital data to help recreate the issue in the correct place. – John Oglesby Oct 15 '15 at 14:43
4

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:

enter image description here

  • 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.

  • 2
    Sure I'm not talking about 'just one picture' bug report) Thank's for your opinion about Full-screen. Not agree about movies 'show the flow that leads to the error' cause this should be described in bug-report's description in 'Steps to reproduce' part, from my point of view picture with description is enough in 99,9% – Ivan Gerasimenko Oct 15 '15 at 14:07
  • 1
    For movies - I would try it out. It's transformed the way I do bug reports and hugely reduced the "i don't get it / can't reproduce it' circle with developers. Your mileage may vary. The description just doesn't cut it sometimes or would be really long and in these cases a movie can be worth a thousand screenshots and descriptions if you'll excuse the misappropriated saying. I don't do one every time but when it relates to workflow and how I got there they are helpful to us. – Michael Durrant Oct 15 '15 at 14:12
  • and yeah steps to reproduce are essential. I didn't put that because I probably would have added lots more once I added that and I wanted to stay on topic and just talk about images. Well, ok, movies too ;) There's plenty of other Q's about good bug reports. The defaults for most OS screenshots is to have datetime in the filename so I allow that to be "as is". This is also to fit in with the lean mean agile philosophy where I don't create such artifacts by rote unless their value add is clear. – Michael Durrant Oct 15 '15 at 14:27
  • Take my words back: movie instead of picture is extremely essential when showing problems in animation! Sure there could be even more examples. – Ivan Gerasimenko Oct 21 '15 at 7:25
4

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.

enter image description here

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.

  • 1
    +1 for the making this a part of induction documentation. Most organizations/teams do not follow these procedures. – demouser123 Oct 15 '15 at 15:33
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.