WhatHappensNext » History » Version 4
TriggerAu, 09/05/2015 12:51 PM
1 | 1 | TriggerAu | h1. How Bug Reports are Managed - i.e. What Happens Next |
---|---|---|---|
2 | 2 | TriggerAu | |
3 | 2 | TriggerAu | So you've submitted the perfect bug report, but your interested in what happens to it after that? |
4 | 2 | TriggerAu | |
5 | 2 | TriggerAu | In a nutshell reported bugs go through a number of stages, and here's some information on those steps (FYI These steps are very similar to the processes the test teams use in QA and Experimental testing) |
6 | 2 | TriggerAu | |
7 | 2 | TriggerAu | h2. Triage/Confirmation |
8 | 2 | TriggerAu | |
9 | 2 | TriggerAu | A number of Test Team members and Bugtracker users spend their own time trying to help people out with issues they see. The first step when a "new" issue is reported is that the bug report is reviewed to check a few things: |
10 | 2 | TriggerAu | |
11 | 2 | TriggerAu | # Firstly, is it an issue that has been previously reported/already a known bug - even though you may search the bug tracker before reporting a bug sometimes we do end up with duplicates. In this case the older bug report will be updated and linked to the new one and the newest one closed as a duplicate. |
12 | 2 | TriggerAu | # Then we look to replicate the issue - is the information and steps in the report sufficient for someone else to be able to replicate the results reported. If people can't replicate the issue using the steps then there may be some back and forth to get some good quality steps |
13 | 2 | TriggerAu | # Adding any extra detail - In this last part of triage we might be adding some details around any missing categories, version specifics, etc |
14 | 2 | TriggerAu | |
15 | 2 | TriggerAu | h2. Investigation |
16 | 2 | TriggerAu | |
17 | 2 | TriggerAu | Once we have a reproducible bug report, the next step is usually to see if we can find the cause of the bug. This involves having good knowledge of the way KSP works and we usually get to varying levels of detail in this phase depending on where the bug lies. |
18 | 2 | TriggerAu | |
19 | 3 | TriggerAu | The aim here is to pinpoint as closely as we can what section of the game is causing the bug, so the developers can get to the meat of issues as quickly as we can help them to. |
20 | 3 | TriggerAu | |
21 | 3 | TriggerAu | You may get more questions at this phase if your bug is being investigated. We may need to ask for more detail or ask you to help with narrowing it down. |
22 | 2 | TriggerAu | |
23 | 4 | TriggerAu | If you would like to see some more of the methods we use when trying to track down bugs we will add some details on methods here shortly |
24 | 4 | TriggerAu | |
25 | 2 | TriggerAu | h2. Escalation |
26 | 2 | TriggerAu | |
27 | 2 | TriggerAu | More to come in this section |
28 | 2 | TriggerAu | |
29 | 2 | TriggerAu | h2. Resolution |
30 | 2 | TriggerAu | |
31 | 2 | TriggerAu | With the development cycle that is used for KSP code changes are committed and tested through releases. This means that bug fixes will be included in each new release. After versions are released we will typically review the open/outstanding bugs and close off the ones that have been resolved. |
32 | 2 | TriggerAu | |
33 | 2 | TriggerAu | This is a background task though, so most people notice their bug being fixed in the release, before the issue ticket is closed. |