Bug Creation - slander36/IssueTrackerTraining GitHub Wiki
Due to how many bugs end up appearing in software, a uniform standard for bug creation is necessary. This guide should inform all bug creation by anyone on the team for the sanity of the people who have to fix them.
So you found a bug…
The first step is to search the bug database to see if it already exists.
If it already exists:
- See if it’s been closed
- If it hasn't been closed, check it's milestone and current assignee to see if it needs a bump
- If it's been closed, in what build?
If you’re on an old build, well, that’s on you. If it’s a new build, however, reopen the bug and treat it as if it was new, and just add the information as a new comment.
What happened?
In order to make the bug as easy to fix as possible, you need to be descriptive. What were you doing up to this point? Is it similar to another bug, and therefor may be systemic? Was this part of the main game mechanics/goal, or did you go out of your way to find it? Did it do something drastic (crash your game or corrupt your save) or is it just annoying (“this texture flickers when you look at it from this angle but only if you’re really far away”). Make sure and write this down in the Description field.
Always reproduce
The next step is to reproduce the bug, (almost) regardless of how long it takes. If you did a good job with your description, you should be able to remember enough to recreate the steps the first time through. The key, however, is that your reproduction must cause the bug to repeat itself. Once you’ve reproduced the bug, it’s time to write down the steps required to repeat it. These must be thorough, I can’t stress this enough. If you say “go over here and do this” that better be all that is required, otherwise the bug will most likely come back to you asking for more information. Regarding the (almost) above: if you can’t reproduce it, then make a note of what you did, but don’t expect it to be fixed, as there is no way for anyone to catch what’s going on and fix it.
How reproducible is it?
Now that you’ve figured out how to reproduce it, how frequently does it happen? Shoot for at least an X in 5 times goal, meaning you tried to reproduce it at least 5 times.
How bad is it?
Severity
This one is tricky, but after a while you’ll get the hang of it. Severity can be thought of on a scale from “OMG” to “meh,” albeit in different terms. Feel free to use the following for severity levels (this is up to the Producer to decide in the end)
- Superficial – visual annoyance, but doesn’t really do much besides make you say “that doesn’t look right”
- Minor – affects the user in some way, but is just a minor annoyance
- Major – affects the user in some way, but can be worked around fairly easily
- Critical – strongly affects the user, but can be worked around after some time (not a show stopper). Example: user must leave the instance and come back multiple times in order to trigger an NPC to finally appear which is necessary to move on with a quest
- Show Stopper – this is a crash, or something else that stops gameplay completely. A broken questline will do this, as will lose of movement, or a memory leak that crashes the game.
Who does it go to?
Teams
Use your best judgement on this one. You will mark your bug for a certain department, and it will most likely get sent to them. However, you’re not always right, and so don’t be surprised if every once in a while you see a bug you created switch departments. Sometimes a graphical issue is for art, and sometimes it’s for programmers, but you won’t know until someone tries to fix it.
When does it need to be fixed by?
Milestones, Sprints,and Build Numbers
Setting milestones is just like ‘who does it go to’ in that the Producer makes the final decision, but you’ll generally know before hand. For example, if Unit 3 is going to be demoed, and you’re testing Unit 4, your bug probably doesn’t need to go in the “Immediately” pile.
Template
Description:
[Description here]
Steps to reproduce:
1. [Step 1]
2. [Step 2]
3. [Step 3]
Reproducibility:
[X] in [Y]
(Severity, Team, and Milestone should all be set in the UI, not in the issue description itself).
