Created By: Game Audio Resource Ltd Date: 28/08/2019 Version: 1.00
This guide quickly highlights why a bug report and tracking software is important not just for audio but all development teams.
The point of a bug report is so that every bug found by QA as they complete test plans is that each issue is logged and assigned to a team or individual designer to fix.
As mentioned in Chapter 17 A, these bug reports will usually be tracked with-in software lke Helix, or JIRA.
This enables production and Development team leads to track project content fail status.
A bug report usually contains generic variables and formatting
Generic Bug Properties
The top section of the bug report presents settings that assisting sorting and finding the bug in the bug tracking software to aid global statistics for production.
The Bug Title
will usually also include development team and project name due to development teams could be working on multiple projects at the same time.
Bug Classes are usually as follows:
Class A = Usually a game progression blocker, game crash or game freeze
Class B = Priority bug, does not crash the game, but degrades the game quality hugely – not really shippable
Class C = Minor low level bug, game could be released with class C bugs.
Class D = Normally “Nice to have” minor fixes, new features, updates to processes or suggestions.
This should be a detailed entry of the bug issue found
This should be a full detailed step by step description of how another person can recreate the bug found.
NOTE: including an in-game screenshot or video to be included with the bug, can be hugely helpful to anyone wishing to recreate the bug on their PC.