Anatomy of a Good Ticket

How to be a better tester, file better bug reports and get better help from developers.

Descriptive Title

Link Color is not a good ticket title. Incorrect text color when hovering on link is a much better title and means the developer does not have to click into the ticket to understand the general issue.

The worst of title of all time is Site not working/Site broken
Something like White screen when loading Product Detail page is a step in theright direction.

Take an extra 3 seconds to describe the issue in context and you save people a ton of time down the road.
But don't go crazy: The 3rd result in a search results page for 'Chicken Soup' looks funny in Firefox v43.9.81 if I disable javascript is too much information.

Just like sending an email, both the Subject and Content areas have a purpose.

Steps to Reproduce.

The more you break down how you discovered a bug, the easier it is to isolate the issue.

For more basic layout/display issues, this can simply be detailed explanation fo where and how you saw the problem:

In the "Recent News" section of the homepage, the thumbnail image overlaps the decription when my browser is smaller than 900px gives a ton of information in one short sentence.

For more complex issues, there are probably numerical steps you can describe to walk someone through how to see what you are seeing and what steps led you to encounter this problem. This trail of breadcrumbs helps the developer reproduce exactly what you were doing and the problem you encountered. Be as specific as you can, as if you're teaching someone and explain what you expected to see vs what you actually saw.

  1. Started as a logged in user (username: george on the homepage
  2. Clicked "My Account" in drop down at top right of the page
  3. Clicked "Edit Profile" under the profile image
  4. Entered new email address 'george@mtvernon.org'
  5. Tabbed to Submit button and hit Enter
  6. Saw this error: "The doohiky isn't connected properly to the whatsit so the thingamabob failed to process the whatchamacallit."

URL

Never ever ever ever submit a ticket without a clickable URL

Seriously. Even if it is a site wide issue, include 1 or 2 example links. Getting a ticket that describes a visual problem is almost completely useless if the front-end developer doesn't know what page you are referencing.

The most common incorrect shortcut goes something like this: My registration date is missing from the account page

Here, the tester describes the page without actually linking to it- you never really know how others have been referring to pages, so "Account Page" could mean one thing to the marketing team, another thing to the UI team and yet another to the back-end developer.

Everything online has a URL and with a quick ⌘+C/⌘+V (or Ctrl+C/Ctrl+V), you can make everyone's life easier and cut down on What page do you mean? emails.

Screenshot.

A picture is worth a thousand words, and it is super easy to take a screenshot. On a Mac, Cmd+Shift+4 gives you use a crosshair to capture a section of the screen. We also recommend Skitch or SnagIt, programs that makes it easy to add notes and arrows. Double bonus points if make a GIF/video of your workflow for complex issues.

Take a screenshot and point out where the issue is/where the missing data is expected to be. Make it large enough to provide context- your image should capture what is wrong but leave enough context to make it apparent where it is wrong. (Of course the opposite is also true- a full page screenshot to point out a 3px variation is not very helpful)

Browser Info.

Especially if you're reporting a design/layout/style problem, make sure to include a line about the technology you're using to test.

IE7, WinXP or Chrome 11, Mac OS 10.4 are both fine examples. Provide the browser version and operating system you are using to help the development team see what you are seeing.

Tools like SupportDetails and What's My Browser make this incredibly easy.

Made by Developers.

This totally awesome site was made by the team at Lat Long. Collectively we've launched 100+ websites/apps and have determined these tips to be the cardinal rules of bug reports.

Final note: if you are using Excel for bug tracking, you are doing it wrong. There are millions of options out there and we recommend GitHub Issues or Trello. All tools have strengths and weaknesses but there are literally hundreds of systems that are better than Excel. Use them.

Other tools like Marker.io or BugHerd go a step further and make this entire process of screenshots, URLs, descriptions and browser info seamless.

Made with pagePiling.js by @alvarotrigo.
Additions? Add them on GitHub