Welcome Everyone Who:

Wants:

· To do right things right first time.

Does not want:

· To do things without value.

Knows that:

· Software Testing never ends, it just stops.

· Software Quality does not happen by accident; it has to be planned.

Believes that:

· There's always one more bug during Software Testing.

· Software Testing is the art of thinking.

Powered By Blogger

Wednesday, April 14, 2010

How do I report a "helpful" bug?

Imagine a customer telling you that your product is not working. You would probably have many questions, just to name a few:

  • How serious is the situation?
  • Is there a defect in your product, or is it in another part of the customer system?
  • Is the issue already known?
  • Is a solution already available?

Now imagine hundreds and thousands of such incidents. How would you analyze these incidents as quickly, efficiently, and accurately as possible?

As QA Engineers our goal is to assist developers in creating a report that is complete and compact.

Complete report allows developers to reproduce the problem quickly.

Compact report helps focus the investigation so that we can quickly determine the cause of the behavior.

There are many bug tracking systems available, but the effectiveness of the system is in your hand, after all, you are the one who is reporting a bug (in most cases).

There are several basic parts of a report. Below are common field for most of the bug tracking systems. All of them are important in one way or another, but in this article we are focusing on

1) Overview

2) Description

Overview

The overview provides us with a background for understanding the issue.This becomes the report's name. A good overview is a unique identifier that offers a rough idea of the issue.

Description

This is a framework for understanding the problem. If you wish, you may include the cause of the problem and a proposed solution. Write as short a description as possible. Use a professional tone and avoid the impulse to vent your frustration.

As long as a report is complete, less is more. Developers tend to review shorter reports first, because their time is limited. By QA spending a little time to a report more concise often results in a faster response time.


Examples

><><><><><<><><><><><><><><><><><><><><><><><><><><><>


LONG REPORT- Vague and Complicated.

SYNOPSIS:

My calculator is not working.

FULL PRODUCT VERSION:

v1, v2, v3

FULL OS VERSION:

Cross platform

A DESCRIPTION OF THE PROBLEM:

My calculator is not producing the right answer. Multiplying two doubles resulted in an imprecise product that is missing the last significant digit.

<><><><><><><><><><><><><><><><><><><><><><

SYNOPSIS:

Floating point multiplication is imprecise when the product has many significant digits.

FULL PRODUCT VERSION:
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)

FULL OS VERSION:

Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM:

Multiplying two doubles resulted in an imprecise product. The virtual machine dropped the last significant digit when the product had many significant digits.

No comments:

Post a Comment