Guideline to creating issues and using the issue tracking system
March 11, 2019 8:49 am | by Jay | Posted in Tech
It’s a normal day and you’re venturing through an online store. Suddenly, a wild bug appears! What would you do now?
The answer is simple. You report this to a dev.
But how would you make sure that the bug really needs to be reported? What if you scare the Devs? What if you get a death-stare for reporting the issue?
What if the Dev didn’t understand the issue at all? What if all the “watchers” are watching each other’s face and no one knows what’s the bug? & why the “highest” priority?
This article is intended to avoid such tedium and use the issue tracking system in an organized way to ensure agile development/maintenance.
This article is divided into two parts, i.e, Guideline to creating issues and Using the issue tracking system.
1. Guideline to creating issues
So, you really decided to create an issue and report it to a dev. Now here is a list of a few things that you should keep in mind to ensure that what you wanted to convey is actually conveyed and make Insect euthanasia a happy thing.
Before you report an issue… Search, and research
Also, keep track of what you find. Even if you don’t find the same issue elsewhere on the site, including links to related issues that haven’t been done can help others in understanding how your question is different from the rest.
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.
Written by Jay
Jay is a SoftwareArchitect at Sarvika Technologies, who fell in love with coding while developing mods for online games. He believes that an individual is defined by mindset and not by degrees. The software quality is of prime importance to Jay, an approach that helps him look at the bigger picture and build sustainable & sophisticated software like CLOWRE.