How to Write a Problem Report

Before sending a bug report, please read the guidelines on writing a problem report.

If you follow these, your bug report has a much higher chance of being processed promptly.

We find two recommendations on the point to be very useful.

Wolfram Research, Inc. recommends:

Please describe only one problem per report. Useful reports include:

• The output given by kernelopts(version)/interface(version) in Maple.
• Your computer operating system, hardware, and memory configuration
  (e.g., Mac OS 9.2.2, G4 dual processor, 256 MB, 257 MB Virtual).
• A one- or two-line summary of the problem.
• Your description of the problem and how to reproduce it.
• The URL of a Maple notebook that demonstrates the problem.

To write an effective description of the problem, you should:

• Analyze the problem so you can describe it in a minimum number of steps.
• Explain how to reproduce the problem. Tell us the steps to see the problem.
• Give a good starting point, and then give details on each step.
• Include error messages and symptoms.
• Explain why you think this is a problem (even if it seems obvious).
• Indicate whether you can reproduce the problem. If you can reproduce the
  problem only part of the time, mention that and see if you can identify
  the circumstances.
• Write a report that is complete and easy to understand.

It is much better to give too much detail than to say too little.

Christopher Creutzig of SciFace Software GmbH recommends

Why You Should Read This

Simply put, the more effectively you report a bug, the more likely an engineer will actually fix it. These bug writing guidelines are an attempt at a general tutorial on riting effective bug reports. You may have to deviate from it at places, but you should always know why.

How to Write a Useful Bug Report

Useful bug reports are ones that get bugs fixed. A useful bug report normally has two qualities:

Reproducible. If an engineer can't see it or conclusively prove that it exists, the engineer will probably stamp it "WORKSFORME" or "INVALID", and move on to the next bug. Every detail you can provide helps.

Specific. The quicker the engineer can isolate the issue to a specific problem, the more likely it'll be expediently fixed. (If a programmer or tester has to decipher a bug, they spend more time cursing the submitter than fixing or testing the problem.)

Show more text

Maplesoft's Guide to Good Bug Reporting

© 2003-2010 Cyber Tester Ltd.

All rights reserved. All logos and trademarks are property of their respective owners.