What should a good bug report that occurs in the game necessarily include? An article for developers and testers.
The author of the original: the developer from Poland Lezhek Gornyak (Leszek Górniak). Game designer at Teyon, Unity developer at Bob Games and columnist at Gamasutra.
Lezhek the Miner
“Some types of weapons do not knock out the damag from the cave troll.” “The indicator shows the wrong amount of ammunition.” “At the third level, the textures flew off.”
Each of these suggestions looks like a bug report. But none of them provides developers with enough information to fix the problem. It is clear that I exaggerated a little with the examples, but in general I have seen a lot of such inaccurate, incomplete and simply incomprehensible complaints. I came across them both while working as a tester in the IT industry, and when I became a game designer.
In this note, I want to show what a good template for a bug report should look like, which can provide a complete, clear and effective feedback. There are ten items in my template:
- heading;
- category;
- importance/priority;
- steps to reproduce the problem;
- what happens as a result;
- what should be happening;
- program version;
- is the problem recurring;
- platform;
- attached files.
Before continuing, I will clarify a couple of points. Firstly, the bug report should contain only the information that will help fix the problem, and nothing superfluous. There are only such items in my template, although some can be excluded if they are not relevant for a particular game.
Secondly, I highly recommend using some kind of error tracking system. Google Docs is quite enough for small projects. But if you have a larger project, then choose a suitable tool that will allow you to categorize bugs, configure filters and priority. I personally recommend Mantis for small projects (10-30 people) and JIRA for larger ones. The problem of ordering error reports you need to solve first.
JIRA Interface
Now let’s go through the specific points of the template.
Heading
Ask the user to write a short title that clearly describes the problem. “Textures flew off at the third level” is a short but insufficiently descriptive title. But “The textures of the materials flew off the skyscrapers on the third level” — much better. From one title, everything that is needed to correct the error is already clear (unless, of course, it happened that the textures did not fly off at all skyscrapers — then clarification will be needed).
Category
Each problem can be attributed to a specific category: Interface, Audio, Dialogs, AI, and so on. Include these categories in the template — this will help filter reports and distribute troubleshooting tasks between different employees.
Importance/Priority
By “importance” we mean how serious the bug is. If one button runs over another in the interface, this is a minor problem. Whereas the crash during the main quest is an obstacle to passing.
“Priority” usually fully correlates with the importance of the problem. Although there are error tracking systems that provide separate filters for importance (Minor Problem, Serious Problem, Critical Problem, Obstacle to Passage) and priority (Low, Normal, High, Urgent).
Steps to reproduce the problem
This is the MOST IMPORTANT part of the report! Without a step-by-step description of the bug reproduction, the programmer will either not be able to detect the problem at all, or will spend too much time and effort on reproducing it. The description should be both detailed and simple. Below I will give some examples.
What happens as a result
This should be the answer to the question of what happens when all the steps from the previous paragraph are completed. Don’t forget that sometimes a single screenshot or log will be better than a thousand words (that’s why the item with Attached files is important).
What should be happening
This is an optional item. Although in some cases the report looks incomplete without it. You need to understand exactly what should have happened if there was no bug.
Program version
Perhaps the error occurs in a specific version of the program, so its number should be included in the report.
Is the problem recurring
Does a bug occur whenever all the steps to reproduce it have been completed, or does it occur from time to time. Ideally, the bug is always reproduced. but there are cases when it is difficult to reproduce it — for example, when the problem is associated with low hardware performance.
Platform
Also an optional item, but sometimes very important. For example, if:
- the game is designed for several platforms, and the bug occurs only on one of them;
- the bug is associated with low performance, which means we need to know the characteristics of a particular device;
- the game is designed for different browsers, and the error, again, occurs only in one.
Attached files
These can be:
- screenshots (they are very useful when the report concerns the environment or the user interface);
- videos (using them, for example, you can demonstrate the strange behavior of AI);
- logs (needed, for example, in case of crashes).
But I didn’t persist for an hour and a half!..
So, we have decided on the points. Now let’s show you how the template works using the examples I gave at the beginning.
Example 1. Some types of weapons do not knock out the damag from a cave troll
Title: The axe does not cause damage to the cave troll.
Category: Gameplay.
Importance/Priority: Critical/Tall.
Steps to reproduce the problem:
- Reach the second act.
- Get into the Dwarven kingdom.
- Talk to Ghotrek to activate the Cave Troll quest.
- Go to the troll’s lair.
- Take up any weapon of the “Axe” type.
- Attack the troll and try to inflict damage.
What happens as a result: The Cave Troll takes no damage.
What should be happening: <Obvious answer, so you can omit>
Program version: 0.3.1.
Does the problem repeat itself: Yes, always.
Platform: Any.
Attached files: None.
Example 2. The indicator shows the wrong amount of ammunition
Title: Too much ammunition is displayed in the indicator after reloading.
Category: Interface (UI/HUD).
Importance/Priority: Serious/Tall.
Steps to reproduce the problem:
- Take a firearm, for example, for 30 rounds.
- Shoot five times.
- Recharge.
What happens as a result: The indicator shows 55 bullets (25 before reloading + magazine capacity).
What should be happening: The indicator should show 30 bullets (25 before reloading + 5 after).
Program version: 0.3.1
Is the problem recurring: Yes, always.
Platform: Any.
Attached files: Screenshots showing the incorrect number of rounds on the indicator.
Example 3. Textures flew off at the third level
Heading: At the skyscrapers on the third level, the textures of the materials flew off.
Category: Wednesday.
Importance/Priority: Minor/Normal.
Steps to reproduce the problem: <Obvious answer, so can be omitted>
What happens as a result: See the screenshot.
What should happen: <Obvious answer, so you can omit>
Program version: 0.5b.
Whether the problem repeats: Always.
Platform: PS4.
Attached files: Screenshot with skyscrapers.
Organized and stable bug fixes significantly affect the quality of the game. Using a clear and unified template for bug reports will improve the work and interaction of your team. And ultimately it will help you make a better game.
Also on the topic:
Source: Gamasutra