information in a tool or document repository. Email is where knowledge goes to die.
Simple Paint Applications
One of my favorite testing tools for reporting bugs is the default Paint or Paintbrush program that comes with any computer operating system. It’s a little high tech in that you need a computer, but it’s relatively low-tech when you consider feature set and complexity. I like these tools because they’re simple, readily available, and good enough to help you create a powerful message.
Years ago, I realized that I needed to capture more information in my bug reports to help explain the problem details. I tried writing more text, but that made the reports too wordy, making it hard to pick out the important parts. In a page full of text, how do you know what the key points are? How do you separate the signal from the noise? Then it dawned on me: “A picture is worth a thousand words.” If I include a good picture, I should be able to communicate more information than by written text alone.
With this in mind, my bug-reporting process now goes something like this:
1. Identify and repeat the problem in the system under test.
2. Take a screen capture. Use a mobile phone camera if you need to.
3. Open the computer’s default paint program.
4. Annotate the picture to identify things like:
a. Where in the app you are (e.g. highlight the page title, web URL, menu navigation, or breadcrumb trail).
b. What data is important to reproduce the issue, if visible on screen
c. The problem (put a circle or a box around it or highlight it with arrows, and add a line or two of text to clarify the problem or expected behavior).
5. Save the marked-up screen capture to an image file (e.g., PNG, GIF or JPG).
6. Attach the image to the bug report.
Sometimes I speak with another team member (via Sneakernet) before I log the bug in step six, and sometimes I don’t need to, depending on the complexity, amount of doubt, and potential impact of the issue found. Regardless of whether or not I log a bug, I have a habit of creating annotated screen captures when I encounter unexpected things. I find them helpful as reminders of what I saw, what I did, and what I thought at the time.
Annotated screen captures are useful for more than simple user-interface issues like spelling mistakes or element misalignments. A good picture may capture the essence of a problem and clarifies the meaning without adding a lot of text to a bug report. Of course, I will also attach log files and any other relevant information to the bug report as required.
Laziness alert! I have seen testers skip the annotation step and add unmarked screen captures to bug reports. This is a mistake. As a tester, you want to provide clear and actionable information. When you provide an unmarked screen capture, you raise the cognitive effort required to decipher the problem and thereby decrease the value of the image itself. It becomes a guessing game. I have seen developers repeatedly ignore these kinds of images and focus solely on the text descriptions to try to identify the problems.
If you want to increase the likelihood that someone will pay attention to your bug report and work on the issue, take a moment to annotate the image and help others see what you are thinking. No one has time for mind-reading in development.
Summary
Although I have identified low-tech tools as being testing tools, they also
About the author
The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.
