Hi Drifters, it’s Damien again, QA Manager for Bossa Studios.
The process of a bug from inception to when it is fixed is actually consistent across the games industry and, in fact, software development generally.
The life of a bug usually boils down to the following process:
The Circle Of (a Bug’s) Life
Bug is Found
I
Bug is Reproduced and Investigated
I
Bug Is Created / Documented
I
Bug is Triaged
I
Bug is Fixed
I
Bug is Retested
I
Bug is Closed
*Sometimes it's not a "new" bug :(
The above workflow is a very simple linear workflow which describes the entire process, but in reality this can be quite a lengthy and complicated process.
Typically, when a bug is found in testing, QA will always first ask the question - “Why did this just occur?” - as the first thing that QA will need to do is investigate the issue in order to ensure that when it is documented, enough information is provided- the important thing is that QA will not need to determine how to fix the bug at this point, as a bug is by definition a statement in what has happened. For example, with a text issue, usually this is fairly straightforward, and thus easy to reproduce, however with more complex technical issues, such as performance issues or, for example, the client freeze, this can be quite a lengthy process, potentially taking days or weeks, from different information sources.
Usually, QA will need to ask questions when attempting to reproduce the issue such as:
- Does this occur for a single player or does it happen for multiple players at the same time?
- Is the bug localised, i.e. does it happen at a specific location, or will it happen anywhere?
- Is there a workaround? For example, is there an intuitive way of working around the bug to be able to continue playing?
All of this is intended to provide as much information as possible about the bug so that it as easy as possible to fix it, as the more information is provided, the easier (in theory) the bug will be to fix.
The next part of the process is what is known is triage, this is the same process as you would have if you go to the hospital, where all cases are judged on equal merit and the highest priority issues are address first. On a game project, this usually will involve all project stakeholders, QA, Code, Production and others to decide which bugs should be fixed and when. This admittedly involves making quite tough decisions, so a risk assessment is made on each bug on a case-by-case basis and everyone provides their different viewpoints in order to decide to fix or not. Sometimes a bug which is really critical to fix may be extremely risky or could be a speculative fix (if it is not completely clear what is causing the bug), so in order to avoid destabilising the game, the decision is made not to fix.
The next step may be obvious, but is probably the most complex, that is to fix the bug. At face value it may involve some back and forth between QA and the development team to fix the bug, either by reproducing the issue with debugging tools enabled (QA typically test the game in exactly the same way as players play the game), or by providing more information as and when required. If the development team have a fix, this is added to the next build which goes into test, and QA then retest the bug in the same way as is defined by the steps to reproduce, in order to confirm the bug is fixed.
So, if QA can reproduce the bug, the bug is sent back to the development team to be fixed again (this can happen several times in some cases), and if it is then the bug is closed, and another bug is squished!
As you can see, a bug’s life can be quite a complicated process in reality involving a number of people across different teams on a project, and a project bug database there can be often thousands if not tens of thousands of bug reports each of which has to be treated equally from the point it is found through to where it is fixed!
Hope you enjoyed a peek into the life and death of a bug!
As always, see you in the skies!