Confirming Tickets

An important part of the bug tracking process is triage, to confirm that a problem that is reported actually exists, and it is a real problem.

Here is another great way for relatively non-technical users to help out. You don't have to be a developer necessary to read a bug report, and check to see if you can produce the same problem that someone else is experiencing. Because confirming a bug is often one of the most time-consuming activities, this is one area where even non-technical users can really help the project.

Bear in mind, bug confirmation is more than saying "me too". It is a process of analytically identifying the exact nature of a problem, and the conditions it exists under, and getting independent corroboration of those facts. Please be disciplined to follow this process through, and refrain from asking for ETAs on the bug tracker (that's not the purpose of a bug tracker).

Triage the Ticket

Often, a bug report is written hastily, and lacks important information, such as:

  • a full description of the problem that everyone can understand (often people will just straight to what they think is wrong, and not the symptoms of the problem. Even if you are a smart programmer, writing the cause without first stating the problem is improper)
  • what they expected to happen (this isn't always necessary, and is sometimes self explanatory, but often what the user is trying to do is a misuse/misunderstanding of how the system works)
  • relavent information such as error messages
  • when the error is known code related
  • the environmental stats where the problem is occurring

See Creating a Bug Ticket for complete description.

When any of the above are lacking, it can help to post a response to the author of the bug ticket, asking for more information, along with tagging the topic feedback.

Confirm that a problem exists

Once you know you have enough information to understand the nature of the problem, and how to reproduce it, try to get your environment set up as closely to the environment described in the ticket as possible. Read the problem description, and what the bug submitter thought should happen. Ask yourself, Do you agree?

Follow the step outlined in the ticket, and see if you can reproduce the problem. Add additional notes if you notice something relevant that the initial poster didn't, such as:
* Include a javascript error that is visible in Web Inspector, Firebug, or IE Developer Tools; * Include a log entry that appears to be related; search google for the error message to see if it occurs outside of Shopp; * If you have the ability, search for the error message in the Shopp code, so you can report the context (file, line) the error occurs on.

Once you have confirmed that the bug does exist, and the software is being used properly, tag the ticket confirmed with your comments.

If it turns out that you could not reproduce the problem, tag the ticket works for me with your comments. There may be something very unique to the reporter's environment which makes the possibility for the problem to reoccur to be rare. It could still be a bug, but it may be less widespread or severe. If no-one can reproduce the problem, it is likely that the problem resides outside of Shopp, and the ticket can be tagged close

The bug confirmation Process

  1. Someone reports a bug, giving details about their environment, and steps to reproduce the problem.
  2. Another person triages the bug report, and if necessary asks for feedback
  3. Another person tries to follow the steps to reproduce the problem, in a close environment to the reported environment.
  4. Tag the issue confirmed if you are able to reproduce, and works for me if it works.

Tags To Use in the Bug Confirmation Process

See the Tagging Guide for a complete listing.

  • feedback — Tag used to indicate that the ticket needs some feedback from the original poster.
  • unconfirmed — Tag for new bug reports that need secondary confirmation.
  • confirmed — Tag for others (not the initial person reporting the problem) to confirm the existence of a bug.
  • works for me — Tag to indicate the someone was unable to reproduce a problem.
New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Plugin e-commerce for WordPress

Shared Ticket Bins

1.3 Development23% complete


Completed 23 of 102 tickets