The Goals of Bug Writing

The Goals of Bug Writing

As with all other forms of writing, it‘s important to remember who your audience is. Usually, the bug will be written for developers and for other QA engineers. Know also that other departments may need to understand the bug: marketing, tech support, etc. You can assume that everyone who may read the bug will have some understanding about the product which the bug is logged against and the technology used. They may not, however, know much about your specific test area.

1. Eliminate basic questions that a Development Engineer might have by including essential information.
2. Understand your audience: make steps understandable for other departments (tech support, marketing) or other testers not in your area.
3. Make searching easier for yourself and others.
4. Write in a way that demonstrates you‘ve done necessary isolation.

Title
Keep the title short and sweet. It should be as explicit as possible in as few words as possible. Think again about what the title will be used for and who might use it. A QA engineer might be looking to match their bug against what‘s already logged and needs a quick way to scan through the titles. Distill each bug to its crucial elements and put that in the title.

1. Try to write in a cause-and-effect manner (―When A is done, B happens,‖ or ―B happens when A is done.‖)
2. Avoid ambiguous wording, such as ―feature is broken/incorrect behavior/does not work,‖ etc. Instead, say precisely how it‘s broken, incorrect, or not working.
3. Use keywords that will make searching for the bug easier for yourself or someone else looking for duplicate bugs. Avoid using jargon, slang, or vocabulary that is too specific to your area.
4. When an assert appears in your bug, include the assert or a portion of the assert in the title(e.g., ―Assert, ‗index < fLength‘ when pasting text into very small text frame‖).

Description

This is where all of the information, the body of the bug, resides: Steps to Reproduce, Actual Results, Expected Results, and any other helpful or vital information regarding the bug.

Steps to Reproduce Bug reports usually suffer from two deficiencies:
1. Too many steps, often poorly organized. Having too many steps in a bug report makes it difficult to read and understand, especially given the confined viewing area in Vantive.
2. Too little information in a bug often leads to unnecessary extra effort and time. Often a bug will be sent back by the engineer as Cannot Reproduce as a result of the inability to follow poorly constructed steps in a valid bug. This can also indicate that you haven‘t completed enough isolation steps.

Essential information to include in Steps to Reproduce:
1. Setup variables: Indicate which printers, fonts, or drivers are necessary to reproduce this bug. Indicate the working OS, if it‘s essential information for reproducing this bug.
2. Environmental variables. For example, indicate if you are working in application or document mode.


Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum