Bug Report Outline

While we appreciate being notified of all problems / bugs you encounter in the software, some methods of reporting are more effective at a speedy resolution.

The following is a brief descriptions of all the components you should include in your problem report:

All relevant files.
A short summary of the problem.
The steps to reproduce the problem.
What you expected to happen.
What actually happened.

Files to Include

Be sure to attach the following files to your support ticket:

The program version and computer configuration are important to know. This information can provided via the GeoMedic Diagnostic Report.
If the program crashes or hangs, you can include a Crash Dump.
Include your project file, excluding the solution.

The Problem Report

A problem report contains four main parts:

The summary.
The description.
The expected results.
The actual results.

The information you include in these parts can make the difference between a quick resolution and one that gets tagged as “unreproducible.”

The Summary

Writing a good summary is often the toughest part of the entire report. A summary must manage to be both brief and detailed. To determine if your summary is appropriately detailed, read it separately from the rest of the report. Does it communicate the gist of the problem? Does it make sense when read alone?

Good summaries:

Crash when deleting regions in SLOPE/W 2D analysis.
Cannot access TEMP/3D license from license server.
Changing base temperature units does not persist over all analyses.

Poor summaries:

The application is broken.
UI hangs.
Solving doesn’t work.

The Description

A good description consists of a list of steps required to reproduce the problem described in the summary. We ask that the description use a “recipe” format, with each action put in a separate, numbered step. It is unnecessary to include the installation and launching of the program as steps, unless this is directly related to the problem. Under normal circumstances, assume the person reading the report has the application installed and running. Avoid including any results in the description, these are best left to the “Actual results” section.

A good description:

Open MyProject.gsz.
Ensure you are in 'Definition' view.
Select the 'Solute transfer:advection-dispersion' analysis.
Select the 'Split Regions' icon.
Left-click on the left side of the existing region.
Left-click on the right side of the existing region.
Right-click anywhere.

A poor description:

When I try to divide regions it sometimes works and sometimes doesn't. It either crashes or hangs.

The Expected Result

This is what you expect the outcome of the recipe listed in the description to be. This should always be included, even if it seems painfully obvious what the expected behavior is. What is crystal clear to you, may not be to us. The expected result can also help us catch design flaws. If we receive a lot of reports against a feature because your expectations differ from the feature’s intended output, it may be time to reconsider the design.

The Actual Result

This is the easiest part of a problem report to write. Simply report how the application behaves when the steps from the description are followed. What is important here is detail, detail, detail. Freely include screen captures. It’s also helpful to report what happens after the problem occurs. Does the app crash or hang? Does it continue normally? Does behave in unexpected ways after the problem manifests?

Problem Reporting Template

Please feel free to copy/paste the following template to help you get started with your problem report:

Summary

Problem Summary.

Description

First step.
Second step.

Expected Result

What should happen?

Actual Result

What does happen?