1. Guideline to creating issues

Write a title that summarizes the specific problem

The title is the first thing a potential Dev will see, and if your title isn’t interesting, they’ll skip the rest. So, make it count:

• Pretend you’re talking to a busy colleague and must sum up your entire question in one sentence: what details to include that will help someone identify and solve your problem? Like any error messages, key APIs, or unusual circumstances that make the issue that you just faced different from similar issues already on the site.
• Spelling, grammar and punctuation are important! Remember, this is the first-time others will see the issue – you need to make a good impression. If you’re not a pro in English – write a draft and ask a friend to proof-read for you.
• If you’re having trouble summarizing the problem, write the title in the last – sometimes writing the rest of the question first can make it easier to describe the problem

Examples:

>A Bad Title: Search not working on “Storename” >A Good Title: Homepage search is giving distorted results on the result page in “Storename”. >Always tag it: QA, BA, Develop, Design

Include the links to the stores in the issue

In the body of your issue, start by putting a link to the store on which you found the bug. If the bug is produced by visiting multiple pages, then link those pages as well. It will help save the time Devs may take, to pinpoint the bug, rather they can utilize that time fixing it.

While a tester asks others to put a screenshot of what changes are made, start by putting a screenshot while creating the ticket. Before & After scenario will be clearer.

Proofread before you publish a ticket

Pretend you’re seeing it for the first time, Does it make sense? Try reproducing a problem by yourself and see, if it is really a problem? Dig into the possible requirements of change. If not needed, even after researching a lot in your reference stores, don’t make it an issue haywire.

Now, is a good time to make sure that your title still describes the problem!!

2. Using the issue tracking system

Assign or Don’t, Let the priorities be set in Workflow of every issue

When an issue is observed, create an issue with no Dev assigned to it. They have their own priorities and unless a request is made by the client for an urgent change, leave it to the Dev team to decide who should do it. There are features of Workflow, in any issue tracking system, let’s start using it.

Post the issue and Do not forget it. Ever!

Respond to the feedback/comments. Leave the tab open in your browser and see if anyone commented. If you missed any important information, be ready to edit your issue to include it. Let the Dev say a word about it, mark the limitations and if he has assigned it back to you, verify it on time before sending it back. A ticket will obviously go back and forth between Dev and you, don’t think of it as a wastage of time because you both exist on the same planet.