As soon as you run into a problem in the software, create a new issue request

In a well-written report, Explain how to reproduce the problem;

Analyze the error so you can describe it in a minimum number of steps;

Include all the steps; 

Make the report easy to understand;

Keep your tone neutral and non-antagonistic;

Keep it simple: one bug per report; and

If a sample test file is essential to reproducing a problem, reference it and 

attach it.

As was already stated, there are many ways of how a request can end “in the trash” instead of being addressed. To raise the chance of an issue being fixed, there are couple 

rules which should be followed. 

This one-line description of the problem is the most important part of the report.

The project manager will use it in when reviewing the list of bugs that have not 

been fixed.

Executives will read it when reviewing the list of bugs that will not be fixed. 

They might only spend additional time on bugs with "interesting" summaries.

The ideal summary gives the reader enough information to help decide whether 

to ask for more information. It should include:

o A brief description that is specific enough that the reader can visualize 

the failure;

o A brief indication of the limits or dependencies of the bug (how narrow 

or broad are the circumstances involved in this bug?); and

o Some other indication of the severity (not a rating, but helping the 

reader envision the consequences of the bug).

First, describe the problem. What is the bug? Do not rely on the summary to do 

this.

Next, go through the steps that you used to recreate this bug.

o Start from a known place (e.g. boot the program);

o Then describe each step until you hit the bug;

o NUMBER THE STEPS. Take it one step at a time.

If anything interesting happens along the way,  describe it. (One must give 

people directions to a bug. Especially in long reports, people need landmarks.)

Describe the erroneous behavior and, if necessary, explain what should have 

happened. (Why is this a bug? Be clear.)

List the environmental variables (configuration, etc.) that are not covered 

elsewhere in the bug tracking form.

If the reader may have trouble reproducing the bug (special circumstances are 

required), be clear about these circumstances.

Keep the description focused:

o The first part of the description should be the shortest step-by-step 

statement of how to get to the problem.

Add "Notes" after the description, if there are any. Typical notes include:

o Comment that the bug will not show up if step X is executed between 

step Y and step Z.

o Explain the reasoning for running this test.

o Explain why this is an interesting bug.

o Describe other variations of the bug.

Combining failures on one report creates problems:

The summary description is  typically vague. Words like "fails" or "doesn't 

work" are used instead of describing the failure more vividly. This weakens the 

impact of the summary.

The detailed report is typically lengthened. Bug reports should not read 

something like the following: “Do this until that happens, in which case do not 

do this until the first thing is completed and then the test case of the second 

part must also be complete, and sometimes you may see this,  but if not then 

that….”

Even if the detailed report is rationally organized, it is longer (there are two 

failures and two sets of conditions, even if they are related) and; therefore, 

more intimidating.

Often, one bug gets fixed, but not the other.

When reporting related problems on separate reports, it is a courtesy to crossreference them.

Sometimes, it is not immediately obvious which steps can be dropped from a long 

sequence of steps in a bug. Look for critical steps. Sometimes, the first symptoms of an 

error are subtle.

A list now exists of all the steps that were taken to show the error. Now, the aim is to 

shorten the list. As each step is executed, any hints of errors must be examined. The 

following factors should be examined:

Error messages (i.e. A message appeared 10 minutes ago. The program did not 

fully recover from the error and the problem evident now is caused by the poor 

recovery.)

Delays or unexpectedly fast responses.

Display oddities, such as flashes, repainted screens, a cursor that jumps back 

and forth, multiple cursors, misaligned text, slightly distorted graphics, doubled 

characters, omitted characters, or display droppings (pixels that are still 

colored even though the character or graphic that contained them was erased 

or moved).

Sometimes, the first indicator that the system is working differently is that it 

sounds a little different than normal.

An in-use light or other indicator shows that a device is in use when nothing is 

being sent to it (or a light that is off when it should not be).

Debug messages: the debug monitor should be turned on (if it exists on the 

system) and should be monitored if or when a message is sent to it.

If, what seems like a critical step has been encountered, everything else from the bug 

report should be eliminated. One must now go directly from that step to the last one (or 

few) that shows the bug. If this does not work, individual steps or small groups of steps 

can be removed.

The failure may look different under slightly different circumstances. For example:

The timing changes if  additional two sub-tasks are performed before the final 

reproduction step is hit.

The failure will not show up at all or is much less serious if something else is 

put at a specific place on the screen

The printer prints different characters (instead of the characters described) if 

the file is made a few bytes longer

This is all useful information for the programmer and it should be included. But to 

make the report clear:

It should start with a simple, step-by-step description of the shortest series of 

steps needed to produce the failure.

The failure must be identified. (Descriptions of how it looks like or what impact 

it will have.)

A section should be added that states "ADDITIONAL CONDITIONS" that 

describes, one by one, the additional variations and the effect on the observed 

failure.

 

Programmers, as humans, operate under time constraints and competing priorities. For example, outside of the 12-hour workday, some programmers are faced with fatigue and apathy, instead of fixing bugs. Some things will often motivate programmers to fix the bug 

The situation with the bug is very poor. 

The complexity piques the programmer's curiosity. 

It affects many people. 

Arriving at the fix is trivial.

It has embarrassed the company, or a similar bug embarrassed a competitor. 

One of the bug`s cousins embarrassed the company or a competitor.

Management wishes for the bug to be fixed. 

The programmer is susceptible to flattery from the person with the requests, trusts the person, owes a favor, or accepts bribes.

 Programmers avoid spending time on a bug due to the following reasons: 

The programmer cannot replicate the defect.

Strange and complex sets of steps are required to induce the failure.

Not enough information is known and it will take a lot of work to solve them.

The programmer does not understand the report.

The solution is unrealistic (e.g. "corner case").

It will take a lot of work to fix the defect.

A fix will introduce too much risk into the code.

There will be no perceived customer impact.

The fix is unimportant (nobody cares about such a minor error or unused 

feature).

It is not a bug, it is a feature.

Management does not care about bugs of this type.

The programmer does not like or trust the person with the requests, or the 

customer who is complaining about the bug