Visualizing Bugs

I’ve recently implemented a different way to visualize our bugs, and am reminded of the above scene from Fight Club.  The new functionality takes location data associated with bugs, and displays them in game, which yields various benefits.  I first give a high level explanation of how this works, and then posit some benefits we hope to see.

As described in a previous post, we make extensive use of live tuning in our day to day workflows.  One thing we take advantage of this for is gathering information automatically for bug submission.  Any member of our development team or QA can run the game, connect to it with our bug tool, and report issues right there, while the game is running.  Since the game is talking to the submission form, it can automatically attach level, location, and other important game state.  As a developer, we can load up the same tool and, while connected to the game, get a list of bugs in the tool that correspond to the location in the world the player is at.  From the list, we can teleport right to the bug location.  Recently we took this a step further, and let the tool tell the game about bugs around the player, and we debug render the description and various properties of the bug.  This has a number of benefits:

  1. before reporting a bug, the submitter can turn on this view to ensure they are not submitting a duplicate, as it would likely have been submitted in a similar location in game.
  2. content creators can use their suite of live-tuning-friendly tools to fix bugs and verify them right in game against the descriptions.
  3. QA can regress bugs right in game.
  4. production can get bug numbers and quotas accurately and visually.
  5. Auto-regression tests can potentially be run for crash reports.

There are other avenues that can be explored for this sort of data.  World maps can be generated with bug numbers, categories, and other data that can be put on the main wiki page of the project to give people a quick overall status, or give production a view at which levels to focus on.  The sky’s the limit!

What helpful methods have helped your team go from a boring spreadsheet of bugs to a more productive way of viewing them?