Testers hate to write lengthy bug description and developers definitely hate to read it. It’s not only time consuming for both parties, but also proves to be counterproductive as it confuses developers about how to reproduce such bugs on their development machines. Because developers hesitate to study such descriptions and execute the reproducible steps, testers are often asked to demo such bugs for the developers, which means rework for the testers. Have you ever wished to replace those extra-lengthy bug descriptions and reproducible steps with more effective methods? Read through to explore how you can make the bug description interesting, effective, easily understandable, and short. One picture is worth a thousand words. Experts agree that visual detail is perceived better and faster than text. For similar reasons, we believe that software bugs should also be graphical and not textual. I was once working with a difficult group of developers. Maybe the tight schedules and work pressure made them behave that way, but they were reluctant to accept bugs from testing. “This bug is not reproducible on my machine,” “Your bug descriptions are pathetic and lengthy,” are a few of the comments I heard every day. In my bug descriptions, I tried to prove the existence of the bug to the developer. I also identified faults in my own bug description and tried to improve on them. Still the developers were unsatisfied. In the process, my bug count gradually went down, which is when I realized the problem lay in my mode of delivery, rather than in the content of my descriptions. The developers didn't have time to reproduce lengthy bug descriptions. In haste, they would execute fewer steps and couldn't reach the bug. Such bugs were marked as “not-a-bug” in the Bug Tracking System (BTS). But if a bug took me ten steps to reproduce, I couldn't have made it any shorter. All steps were equally important for the bug to appear. This is when I decided to capture the series of steps in a movie file and supply it to the developers. When they ran it, they were guided through the mouse-clicks, data input, and screen actions to reproduce the bug. What could have been a better way to substitute ten steps into a single movie file, which also saved time, arguments and confusions? What is a Bug Movie?Bug movie is recording the sequence of user interactions in a video combined with audio assistance and customized annotations that can be shared and viewed by anyone using standard media player. The typical components of a bug movie are

1. Visual display of the series of steps as they happen on screen
2. Recorded voice of the tester narrating specifications of the bug
3. Annotations on the screen to specify visual details

Having this type of “Show and Tell” power will make the bug more understandable. How to shoot a bug To shoot a bug, all you need is an extensive screen/action capture tool/utility. Such tools are available free or for a nominal price. They allow users to capture still pictures as well as streaming screen-shots. There are a number of programs that enable screen recording (SnagIt, Screen Thief, ScreenWatch etc.) on various platforms. These dynamic screen recording and capturing applications are designed to create content that can be streamed to virtually any PC desktop using Real or Windows Media. They enable the user to create high quality recordings with full size, full color, and full motion content that precisely replicates the user experience. A few such tools also allow users to record audio along with visual display. Testers can use this facility to record useful information pertaining to the bug that is not quite evident in the video, e.g. “Wait for 5 seconds before submitting,” “Press the Esc button,” etc. Users can also annotate portions of the screen, thereby highlighting important details. While the tester is reproducing the bug, the tool records the bug in a movie file. The tester then enters the bug into the BTS and attaches the movie file to that particular bug. As the developer clicks on the bug to view details and runs the attachment, the respective movie file starts playing on her machine showing a pictorial representation of the bug and guiding her through the sequence of steps. The tester doesn't need to type out textual details of the bug, and the developer doesn't have to manually execute the steps to reproduce it. It Helps

• While entering steps to reproduce, it's likely the testers will forget to mention all environmental status of the application. A small amount of data could have contributed to the defect, which the tester may have ignored. A recorded movie clip displays the complete status of the application when the defect was found.
• No matter how good your communication skills are, there will always be some developers who face difficulty in interpreting the bug correctly because methods of expression and written styles differ from person to person. This experience is worse when developers and testers come from different demographic regions, which increases the probability of confusion between two groups. A graphical bug, on the other hand, eliminates these issues.
• Isolated development and testing groups often spend time in bug clarification cycles. As the groups are not available at the same physical location, it delays the clarification process, thereby reducing quality time that should have been spent rectifying the bug. A multimedia bug reduces the need for bug clarification, as it is easy for developers to assume unclear information.

Watch outTesters will definitely love the idea of not having to type out bug description and will try to record each and every bug into a movie file. It certainly is a simpler and more effective method, but it can't completely substitute for the conventional textual method. A bug that is better understood textually should be left that way. Unnecessary application of the concept may otherwise prove to be hazardous.

• Multimedia bug files consume more hard disk space making it difficult to maintain a bug archive.
• It’s heavy on machine resources while recording and viewing multimedia bugs.
• It reduces testers’ analytical capabilities. Testers often don’t wish to narrow down the bug to minimum reproducible steps. Because it’s easier to record the steps than to type bug description, testers are tempted to file the bug early without spending time in eliminating unnecessary steps.
• Though not intentional, this concept reduces team communication between development and testing groups.

Consider a graphical bug if

• The reproducible steps are lengthy, making it difficult for tester to type and developer to rerun the steps
• It’s difficult to reproduce every time
• Impact is high severity
• It’s difficult to convince the developer that the bug exists
• It’s confusing in nature

One good rule to keep in mind is that the less frequently a graphical bug is used, the better it will grab the developer's attention. When it shows up, the developer will immediately consider it a high priority, difficult-to-reproduce, and risky warning. To get the most of it, use the concept sparingly. Let your bug’s character speak for itself through the bug movie.