Contribute a bug report

Owned by Stefan Siegl
Last updated: Jun 29, 2015

Reporting a bug is very helpful to inspectIT. We try to keep quality as high as possible and test inspectIT on various environments with automated tests and manually. Still in software development there will always be problems. Reporting these problems is the first step of solving them. Simply click the following image to create a bug (or navigate to JIRA and create a bug manually).

click to create a bug report

   click me to open a bug report

Guide

  1. Check if this bug was reported already: Before creating a bug report it would be great if you check if this bug is already reported. Go to https://inspectit-performance.atlassian.net/secure/Dashboard.jspa and use the top right search box. If you find that the bug was already reported, please comment on the ticket and improve the bug description. You might also want to Vote on the bug. Voting helps us to understand which ticket is the most important to you, so we can plan our development.

  2. Provide information: It sounds stupid but, the more information you can share the easier it is for us to understand the problem and thus fix it. See "how to write great bug reports"
  3. Be ready for questions or checks: It is very helpful if we could ask you to clarify things. Also it might be that we do not have the environment that the problems occurs. In these cases it is very helpful to use if you could test a fixed version and assure that the bug is really fixed.

How to write great bug reports

Select a meaningful title

The title is the face of your report. It’s the first thing anyone sees and it’s importance cannot be overstated. A good title helps reduce duplicate issues and can quickly convey a summary of the bug.

It’s best to avoid generic problems in the title. For example, these should never be used:

  • XYX is not working properly
  • Issue with XYZ
  • XYZ is corrupted/does not look right

The above example titles add little value in describing the problem. By nature, every report is describing something that is not working as it should. Be specific about what makes it “not working.”

Instead of: Sorting is not working properly.

Try: Sorting is happening in reverse order.

Instead of: Issues with GUI on navigation bar.

Try: Navigation bar is wrapping to a second line.

Often times, bugs are migrated into the developer’s database that may contain hundreds, if not thousands, of other issues. Imagine trying to search this database for “navigation bar”. That search will return every issue related to the navigation bar. Searching for “wrapping to second line” is much more specific making it easier to find the bug. Your bug report needs to survive (and be useful) beyond the current test cycle; a strong title will help it through it’s journey.

Explain how you encountered the bug

This is the body of your report. The goal of this section is to show the reader how to reproduce the bug. Since this area usually contains the most information, it’s important to keep it concise and easy to read. Always number your steps and kept them short and to the point.

Tip: Using a prerequisite can reduce the number of steps.

Instead of listing out every step to login in, start your steps with: “Prerequisite: User is logged in”

Tip: Find the direct path to the bug

Often times, testers will stop at the point where they found a bug and log their last few actions. However, the most helpful bug reports are those that distill the report down to the core reproduction steps.

It’s a good exercise to reproduce the bug by following the steps you’ve just outlined. This will help ensure you’ve included everything the customer will need to reproduce it as well.

Sometimes digging a little deeper below the surface of the bug can add additional value. Here are some examples of how adding a bit more effort or thought will produce a higher quality report.

Example 1: Provide additional useful information

Scenario: You find that a video does not play.

Good: Mention if it happened on all videos and not just the one mentioned in report.

Better: Specify if the issue is reproducible on more than one browser or device.

Best: Upload a speed test showing that bandwidth was adequate when testing was happening.

Lesson: Try to identify and answer follow-up questions before the customer asks them.

Example 2: Report the bug, not a symptom of the bug

Scenario: We are testing an Address input field. We find that the Address field allows “1234567890” and it also allows “!@#$%^&*()_+”

Lesson: These are two different symptoms of the same bug. Closer inspection would reveal that the real issue is the Address field isn’t being validated at all. The problem may be more serious than the first symptom you find.

EXPECTED AND ACTUAL RESULTS – WOULDA, COULDA, SHOULDA

Now that you have described how to reproduce the bug, you need to explain the problem and the desired behavior.

Tip: When describing expected results, explain what should happen, not what shouldn’t happen.

Instead of: The app shouldn’t crash, Try: The user is taken to XYZ screen.

Tip: When describing actual results, describe what did happen, not what didn’t happen.

Instead of: The user wasn’t taken to the XYZ screen, Try: The user remained on the ABC screen.

 

ATTACHMENTS – WHAT TO DO AND WHAT NOT TO DO

Attachments add to the bug’s value by offering proof of the bug’s existence, enabling us to reproduce it or helping the developer fix it. Each attachment should add to the value of the bug in at least one of these three ways. The following are some tips and guidelines to keep in mind when adding attachments:

IMAGES

  • Adding images is a quick way to add context to your bug. Consider adding an image even if you also have a video.
  • Highlight the area(s) of interest in your image.
  • Attach the image files directly to the report. 
  • Use images to illustrate static issues.

VIDEOS

  • Video confirms your steps were accurate at the time the issue was created. For example, a screen grab of an error message isn’t as useful as seeing what went into creating that error message.
  • Actions in the video should match the steps listed in the bug report.
  • Videos should be trimmed to only show the bug.
  • Provide video if the steps are complex.

LOG FILES AND OTHER TIPS

  • Avoid proprietary file types (like .docx). Use .txt instead. If all you have is Word and you want to include some nice pictures, you could do that and convert the whole document to PDF.
  • You can compress (.zip) the files if necessary.