Working as a video games tester is not all (ahem) fun and games. When you discover a bug you need to report it. When I worked as a video game tester for Electronic Arts I found over 1000 concerns in under 20 months. I found over 57 issues in one game alone. It took me two full working days to write up the bug reports for that title. Hopefully, if you are starting out in the video game industry, my comments may be of some assistance.
Writing a video game concern might seam like a simple task but it comes with with a great deal of responsibility. This is a communication from which other people will base a plan of action on. Those actions often include committing costly resources to resolving the issue. Here are some tips from my experience as a video game tester.
How to write up good video games concern/bug report: A good video game concern report contains:
Title (the 'Subject', if you report concerns by email):
- Summarizes the important factors of the issue.
- Simple overview of what, where, when, why and how it is caused, highlighting the most important considerations.
- Indicates how severe it is.
- Is used by others to plan a course if action, so it needs to be understood at a glance.
- Succinct description of What, where, when, why and how it is caused without leaving out any details.
- Here you should describe accurately EVERYTHING about the concern.
- Describe it in such a way that the reader can reproduce it SOLELY from the description and understands completely what is happening.
- You may use industry standard jargon to help accurately describe the issue.
- Step by step guide on how to reproduce the concern.
- Written for nincompoops. You should assume the person following this guide has never seen the software and may even be new to the platform. Show them EXACTLY what to do to reproduce the issue.
- Avoide industry standard jargon to ensure the steps can be followed by anyone.
- Additional useful information
- Opinion and speculation, you can talk about how this bug might affect the player and possible eventualities caused by the concern (bad reviews or dissatisfied customer for example).
- Observations about other ways this might affect the game.
TIP. Essentially the information you will write in the title/description and reproductions steps will be Repeated. Take the opportunity to describe the same thing in a different way as this aids clarity to your observation.
Lets take a look at an example:
Consider the bug report title "Game crashes in online multiplayer lobby".
On the surface of things, this looks like a good title, but it's not. It does not tell enough of the story and it makes it harder to manage at a glance. The concern title must help all involved to have an idea of what action may be necessary preferably without having to read the entire contents of the report.
Superfluous details. First you don't need the word "Game" (or "title" depending on where you work). Everybody knows your not testing washing machines, you don't need to remind them, especially true if the concern is already linked to the game in an internal the bug tracking system. If it were an email, you might actually need to name the game, but for most systems every one knows what you are testing when you post the concern in the system under that heading.
Even the words "online multiplayer" are probably not necessary, if the crash happens in a loby then it must be for lan or online play. This is taking up space which might be better used.
At the end of the day only you can decide what is pertinent to finding, explaining and reproducing the bug. It will be enough if you take a few seconds to think (it's why you have a brain); "does this line help people to understand quickly and accurately what is happening and how significant this issue is". If it does, you've done your job.
Lets see what I might have written and why: "Adding 4th player in lobby causes hang, reset required"
- "Adding 4th player in lobby" - the cause of the concern. Notice how the original title of the concern (above) didn't talk about WHAT caused the concern. In my hypothetical example, let's say that adding a forth player causes the issue. It's important to mention it only happens when the forth player is added because this helps people understand how severe it is. Put simply you need to help people to see at a glance how bad the problem is.
- "causes hang". Depending on where you work there will be specific terms referring to what most people call a crash. A "hang" is a common term for 'game freeze'. Terminology at your place of work may vary, make sure learn the right terms.
- "reset required" again shows how significant the issue is. The other title failed in this respect.
- What I didn't say. Also note that because I stated the whole title as simple fact without reference to how often it occurred this implyd it occurred all of the time. A 100% reproducible bug almost always has a high severity (only not if the user is unlikely to experience it).
TIP: Think of your title as a newspaper headline. You have only a few words, use them to describe the concern accurately. Like a headline feel free to play loosely goosey with english grammar if it helps you explain the problem in this limited space.
In the Description, you expand on the title. Explain exactly what the problem is and how, when, why and where it happens. My style is to make sure everything is clear enough that anyone who reads the description would be able to find and re-create the issue without needing reproduction steps even though I include those as well.
In our example:
With three players already connected and waiting in the lan lobby a 100% reproducible hang occurred directly after adding a forth player. A hard reset was required.
I don't like to say "during testing the user found" because it's superflous. I mean, the tester didn't find it while going to the toilet right?
Notice it's alot like the title. That's good. The description is a great way to check your title! If there is an important fact in the description thats not in the title, see if you can work it in cleanly.
Reproduction steps should be a step by step guide on how to reproduce the error. Include onscreen text, buttons pressed and explain exactly what the user has to do to make it happen.
For me, reproduction steps are the perfect way to put something another way and show any idiot reading it how to recreate the issue and also provide a redundant check for your work. You may not notice ambiguity creeping into your description but the reproduction steps will help others if it did.
For our example:;
- Using three connected consoles enter and online loby, connect to the same game and "ready up"
- On a fourth console either search for, (or accept an invite for) the online game in which the others are already present.
- Press the "o" button to enter the lobby.
- Observe then game hangs on all consoles.
Simply put any other pertinent details here. This section is not a requirement. If you are communicating the concern via email, additional contact details may go here. Before you finish, stop and think if anything you have written should be in the description
In this example you might talk about that fact that other players will be affected by the bug.
I hope that helps write up good video games concern, good luck with a career in the video game industry.