Get the latest Education e-news
 
  • How To Report Bugs

    [06.28.18]
    - Leszek Gorniak
  •  Cave Troll cannot be defeated with some weapons.

    HUD displays incorrect amount of ammo.

    Graphics in level 3 is broken.

    Each of the above statements describes a potential bug in your game. However, none of them provide information required by programmers or designers to fix the issue.

    Those are, of course, a bit exaggerated examples. Nevertheless, I've seen way too many imprecise, incomplete and even incomprehensible bug reports, both as a QA specialist in the IT industry and as a developer and designer in the game industry.

    In this post, I'd like to present a bug report template that is, in my opinion, clear, effective and sufficient. Here it is:

    • Title
    • Category
    • Severity/Priority
    • Steps to Reproduce
    • Current Result
    • Expected Result
    • Affected Version
    • Reproducibility
    • Platform
    • Attachments

    There are two important remarks before I move on. Firstly, reporting bugs is all about communicating all that's required to fix a bug, and nothing more. The main purpose of the above template is to provide such information. However, note that not every bug report must include all points.

    Secondly, using some sort of a bug tracking tool is more than advisable. In case of very small projects, Google Docs could be a sufficient solution, but for more complex projects you're going to need a tool that enables you to categorize, prioritize and filter bugs. I personally recommend Mantis for small and medium projects (10-30 people) and JIRA for big projects (30+ people). Keeping reported issues in order should be considered the first step towards fixing them.

    Title

    The title should be short and descriptive. Graphics in level 3 is broken surely is short, but not really descriptive. Skyscrapers in level 3 don't have materials applied sounds better, and in this particular case the title alone might provide enough information to fix the bug (unless not all skyscrapers are affected).

    Category

    Each bug's occurrence can be narrowed down to a specific game project area: User Interface, Audio, Dialogues, AI, etc. Such a category should be included in the bug report, as it helps to filter out a specific type of issue and points to a person/team to which a given bug should be assigned.

    Severity/Priority

    Severity describes how "harmful" a bug is. Slightly displaced UI button is a Minor issue, while a crash that prevents a player from completing the main quest is a Blocker. 

    Priority is in many cases directly proportional to Severity. Bug tracking tools usually have a separate drop-down menus for Severity (e.g. Minor, Major, Critical, Blocker) and Priority (e.g. Low, Normal, High, Urgent).

    Steps To Reproduce

    This is the most important part. Without a detailed step-by-step instruction on how to reproduce a bug the person responsible for fixing it won't able to do it or will spend too much time and effort investigating how to reproduce the issue. Listed steps should be as detailed as needed (knowing what's needed comes with experience) but also as simple as possible. I'll give some examples later on.

    Current Result

    Basically, this should answer the question "What happens after I perform all steps listed in the previous part (Steps to Reproduce)?" Bear in mind that sometimes a single screenshot or error log says more than a hundred words (see Attachments part).

    Expected Result

    This one is not always required, but in some cases the report is incomplete without indicating what actually should happen in a correct scenario (if there was no bug).

    Affected Version

    If you found a bug in a specific build that has a version number or code, this code should be included in the report.

Comments

comments powered by Disqus