Developer for Nuclear Dawn mod (May 2005-Dec 2008) :: QA Tester for SEGA Europe (Dec 2007-Aug 2009) :: Production Tester for Splash Damage (Aug 2009-)
A reference guide for testing mods. Includes info on how to find bugs, how to narrow down the steps to reproduce and how to write good bug reports. Also includes a 'game development terminology' reference section.
Posted by Crispy on Jul 25th, 2008 digg this super bookmark
Page 5 of 11
Intermediate QA/Testing.
What to do if you find a bug
Communicate:
As a tester, the first thing you need to do when you find a bug is to tell everyone else about it to create a general sense of awareness. This will mean other testers are more focused so if they do find the same issue, they will be able to provide more information on how to attempt to reproduce it. Reproduction is the second course of action. Try to recreate it by doing exactly the same thing you did before. If this still produces the same effect, you need to try to narrow down your steps by changing one condition but keeping the rest the same.
Information gather:
The best first step is to try to note down as much information about the incident(s) as possible. When you write a bug you will need to include most of this information in any case, what you need to do next is eliminate any information that isn't specific to the bug. Remember that hardware and software settings are also 'conditions' for the bug. It could be that the game is asking your graphics card to do something it can't, it could be that you have on-screen text turned off and the game is trying to give you a tutorial message that conflicts with this option setting.
Eliminate:
The greatest detective of all time once said: "If you can eliminate all the other choices, the remaining choice, no matter how improbable, is the answer." Once I spent 4 hours trying to figure out what was producing a 100% reproducible crash in a game. When I tried it with another game disc it still occurred, but when I tried it on a different machine it didn't occur. The only conclusion left was that the hardware (the console) was unreliable. Usually we go into testing assuming that the tools we use are there to help us find problems, but as a tester you have to consider that sometimes they can be part of the problem themselves. Ever since that experience I always make sure that I check in the early stages that hardware isn't the cause of the issue, I'd advise you to do the same, especially when talking about PCs that have many different pieces of hardware to keep track of.
Eliminate conditions beginning with the most general. One of the first things you should try if you can do so easily is to try to reproduce using the same conditions on a different machine. Other general conditions could be to see if the same bug can be reproduced on a different level, with a different weapon, with a different class, against a different enemy. If it's a graphics issue see if it occurs on a different resolution. Try to ascertain how exact the steps need to be for successful reproduction.
Reproduce:
Reproducing is really part of the elimination process, but even when you think you have the answer you really need to remember to try to get another tester to reproduce the problem using what you have written as a guide. Sometimes you might have missed an important bit of information that will be uncovered when the other tester fails to trigger the bug using your steps to reproduce. Sometimes this missing information is the key to what is causing the problem in the first place.
Only registered members can share their thoughts. So come on! Join the community today (totally free) and do things you never thought possible.
very useful for beginning moders! gj
and for experienced ones to :)
required read for every modder :)
Interesting read, I myself have tested a few mods now and still am so I'm quite familiar with some parts in this tutorial. However, it felt like some parts were mostly for single player games/mods but it's good that you managed to cover all parts. Good job and keep your tutorials comming! I will definitely show this to my fellow testers.
Hi! I know it's some time since you made this comment, but I've updated the Bug Hunter section with some ideas for multiplayer testing anyway.
This is a very good read. I have been testing games for a while, and this clearly explains all of the characteristics of a bug that a game tester must explain to the developer. This is a must read for any developer/game tester, since it shows how much organization can help you in the bug-fixing process.
I thought page three was a bit too deep and overcomplicated for most mod teams - it doesn't need to be so formal in a small team. Might be valid for one of the few really large mod teams though.
The rest of it is spot on though - if all bug reports were done to this standard I'd be a very happy developer :)
Funnily enough this piece started off as part of a bigger tutorial, which I then decided to split into one for QA testers and one for QA Leads. When I wrote the introduction to what will now be the management tutorial, I put in a warning that small mod teams don't need to exhaust their efforts on fancy bugtracking software if they're only going to have 500 bugs in their database. There's no point writing up playthrough testplans if all you're changing is some weapon models and variables.
The same is true of testing to a certain degree. As far as a tester is concerned, the main points to focus on whether you're a big or small mod fall into two areas:
1) Bughunt actively, don't wait for bugs to come to you
2) Communicate information with the whole team in mind, whether it's a bug report or a fix.
What parts from this tutorial you choose to apply to your own testing is down to the scale of the project. Ultimately the QA Lead should be setting the benchmarks for your mod's bugging practise, which is what the next tutorial will look at.
Thank you for making this tutorial Crispy. :-)
I have already sent a link for our beta testers, as there is a LOT to learn from this article.
Personally, being the beta team leader of our mod, I can't wait to read your upcoming QA management tutorial. ;-)
OH MY GOD this is so awesome.
Looking forward to your QA Lead guide
Good work Crispy.
Thanks for the kind words.
If you have any D class bugs of your own, I am taking all feedback on board to work on improving the tutorial and making it more relevant to more teams. Based on the comments so far, I'll be looking at adding in more stuff relevant to multiplayer testing and also trying to make it clearer what is applicable to smaller mods.
Very interesting read, Crisp.