Crispy Mod Tester's Handbook tutorial

Introduction

Why test?

When you design and create a game you usually do so according to a vision. Your aim is to get the game to accurately convey this envisaged experience to the player. Since your vision is usually focused on making the game fun and enjoyable to play, you won't always consider areas of the game that could be manipulated or overlooked to result in confusion, frustration or boredom. In essence, the purpose of testing is to give developers a new perspective on their creation. On almost every occasion, testing will have a developer saying to themself: "Oh, I didn't think of that." or "I can't believe I forgot to do that." Testing is about anticipating player perceptions to the game and giving developers a second chance at improving their creations before they reach the end-user.

Who should read this tutorial?
This tutorial is aimed at everyone involved in the QA process, which is basically everyone on your mod team from testers to developers. Anyone who is writing or editing bug reports should be reading this tutorial.

For testers
I made the tutorial because it seems most people testing mods don't actually know how to really probe the game and push at its limits. Most mod testers (appropriately named 'playtesters') simply play the game as normal and note down anything they happen to see. They don't go looking for bugs, or creating bugs by being inventive, they simply stumble across them by chance. These people are playing the game, not really testing it, and that's why I made this tutorial. The tutorial has been written in such a way that it does not apply specifically to any platform or any particular genre, this is so that any tester for any mod can glean some information from the handbook and apply it to their project, whatever it may be.

For developers
I especially stress the need for developers to be familiar with good bugging practise. The amount of times I've been looking for a bug in a database and seen ambiguous, unhelpful bug summaries like:

This not only forces the reader to open the bug to try to find out what it's about, but it means that nobody else on the team is going to find the bug via a keyword search. It's an accumulation of bad communication like this that wastes time and pushes back development. Help your team by being as transparent as possible in your documentation at every stage of development.

It's amazing that this sort of lazy approach to bug reporting doesn't vary from studio to studio, even when you look at industry-leading developers you still get time-wasting bug summaries like these, often without much more explanation in the bug description. Part of the reason they do this is because they assume they're writing this bug for people in the office who can come up and ask them if they have any queries. Remember that in modding the majority of the time we don't have the luxury of face-to-face discussions, so make sure your bugs are as descriptive and clear as possible, whether you're a tester or a developer.

For QA Leads?
Of course, whoever is managing your testing process should read this and be familiar with good bugging practise, but if you're more interested in setting up a test schedule, deciding on testing strategies and managing bug databases, I am also writing a separate tutorial for mod QA leads that deals with the management side of things. Keep an eye on the tutorial section for this or just watch my profile to be notified automatically when it goes live.