Mod Tester's Handbook tutorial - Crispy

The QA process

The lifecycle of a bug

This is a list of all the stages a bug may go through during its life. I've included it here because it contains many processes that many first-time testers are unaware of. It's easy to assume on the outside of development that bugs are found, reported and fixed in a flawless process that goes from A to B without hiccups. The truth is that errors are made and multiple checks are in place to make sure that developers don't waste their time trying to fix duplicate bugs that are already fixed, or that fixes the developer has made on their own version actually make it into the game and aren't left out by accident.

This is where a lot of double-checking and a hell of a lot of communication come into play. These areas are vital to quality assurance and are there to save time in the long run. Any bugs in your database should be going through most of the following steps:

1. Discovery The bug is discovered by a developer, tester or perhaps a player.
2. Communication The testers/developers are notified of the problem. A player will make a forum post or send an email, or perhaps tell someone in-game or in an IRC channel. This needs to be logged immediately and passed onto whoever handles QA. On the other hand a tester or developer will need to talk to their teammates and check the bug database. Perhaps the issue has already been found and a report exists? Perhaps you need to edit the report with new information?
3. Investigation A developer or tester should investigate the bug. Perhaps it is a design feature that has been misinterpreted by the user. If it is a bug, the tester will need to document which conditions the bug can be reproduced under and how reliable these steps are.
4. Documentation A bug report is logged in a bug database with information including a search-friendly summary, description, steps to reproduce, reproduction rate, priority, seriousness,etc.
5. Verification The bug is checked by a senior member of QA for clarity, accuracy, significance and urgency.
6. Assignation The bug is assigned to a particular member of staff to be fixed or discussed. This process can go back and forth between team members. Whenever a bug is assigned to someone a reason must be given, e.g. "NMI" (need more info), "NAB" (not a bug), "not an art issue - maybe an error in the code?", etc.
7. Fix An attempt at fixing the bug is made. Some comments briefly describing the solution should be added to the notes so that expertise is shared across the board and similar future issues can be dealt with quickly.
8. Regression The fix is committed to a build of the game and that build is tested. The result of the regression is logged in the bug entry, e.g. "Fixed" (plus the name of who reported it fixed), "Fail" (plus details of why it failed; the attempted fix may have created a different issue), "CNR" (cannot reproduce; plus the reasons for this).
9. Closure The bug may be closed after regression or even before a fix has been attempted, but a reason for closure must be given, e.g. "Fixed" (regressed as 'Fixed'), "Closed - as designed" (not actually a bug), "Waived" (the bug has been deemed too low a priority for this release, "Duplicate" (the bug has already been reported; a link to the duplicated bug should be given).
10. Re-opening If a bug has been waived for one version, it may be re-opened to be fixed for a later patch when priorities and focus are re-assessed.