Give some context
In most cases, the most important audience of a ticket is the person who has to implement a change. That individual may have built 90% of project or may have been on-boarded yesterday. Consider that the person implementing a ticket may not have all the references and back story that you have. “Menu still having issues” is not useful information to someone who has not seen the original bug. Since a project or task may be on hold or put in backlog, think about whether the ticket will still make sense in a few weeks or months.
For All Projects
You should always include one or more urls in a ticket. Even if it seems obvious (“Home page doesn’t load”), a copied and pasted url can reveal extra information, like whether the user is accessing via SSL and what environment is being used.
It is not uncommon to have errors reported for a “dev” environment when the tester should have been working on a “test” environment, or vice versa. The url is a reference that helps ensure a common starting point.
For Front-End Tasks
A picture says a thousand words. What is unclear from a description can be quickly illuminated with a screenshot.
Bonus points if you use a tool like Skitch or King to annotate the screenshot. An arrow or a red box and some text can go a long way. I’m a fan of Preview, which comes with Mac OS X, and Jing, which can also handle video screen captures.
• Device/OS/Browser version
Your device is the physical object that you use for testing. Examples are Android phone, iPhone, Windows phone, Galaxy, Kindle, iPad, MacBook Pro, and Dell.
You OS is the operating system, the software that runs the whole device. Examples are Windows NT, Mac OSX, Android OS, and iOS.
Your browser is the particular app that you are using to view the website. Examples are Firefox, Internet Explorer, Chrome, and Safari.
The matrices of devices and operating systems seems infinite. Usually you can find the browser version in the “About ..” menu item.
When adding details to a ticket, you get bonus points for testing in multiple browsers. “Submit button is too wide in IE8 but looks fine in Firefox 43, Safari 9 and Chrome 47” is a great note!
For Back-End Tasks
• Steps to reproduce
There is often more than one way to accomplish a task on a website. When documenting functional bugs and requests, listing the specific steps to trigger the bug or get to a particular screen can be very helpful. State whether your results are consistent or intermittent.
• Actual Behavior vs Desired Behavior
Describing a request in these terms can often help to clarify it.
It's important to indicate user and role states when documenting tickets. Were you logged in? Logged out? What was the username?
In Drupal, users often have different permissions and see things differenently depending on their role.
If you have access to multiple user accounts, see if you can you reproduce the same results with a different role and document your findings.
- Sprint # - The cycle of time (usually 1 or 2 weeks) during which the work will be done.
- Component - The part of the system (Examples: Theming, Blog, Shopping Cart, Menu System, WYSIWYG).
- Deadline/Estimate - The amount of time or effort you estimate the task will take. Some teams report this in hours, others use story points.
- Priority/Severity - How should the task be prioritized? It is Low, High, Critical Post-Launch, or a Launch Blocker?
- Type - What type of ticket is this? Is it a task, bug or feature request?
- Dependencies/Related tasks - Is this task dependent on other tasks?