Introducing the Quality Assurance Pipeline

Like other production pipelines used in the development of video games, quality assurance has its own pipeline as well. It helps to see it this way because it makes managing bugs as tasks a much easier process. The game quality assurance pipeline is divided into five key steps. They are the following: Find, Report, Assign, Fix, Regress.

1. Find

This is what game testers are assigned to do on a daily basis. They will play the game according to the test plan laid out by the QA Lead and production staff - usually assigned by specific levels or areas of the game to focus on to maximize overall coverage of the product. Techniques for discovering bugs can be covered in another topic. However, game testers will try in a variety of ways to break the game and find issues with other factors such as mechanics, audio, graphics, etc.

2. Report/Classify

Once a bug has been found, it must be reported in a clear and concise manner. It is best to use a bug or task tracker no matter how large or small the project is. While the paid options are definitely the best there are some excellent free products out there as well that will suffice. (Please note, I use "bug" and "issue" interchangeably.) A bug report starts with a brief summary or title - sometimes with shorthand for issue type, area of the game, etc. It has clear steps to reproduce the issue. It will have the number of times the tester attempted and successfully reproduced the issue (usually no more than 5 attempts), It will have a description of the result when the steps are followed. And if needed there will also be an "expected result" if the tester believes something else is supposed to happen. Classifications of bugs are usually done with a scale ranging from A through D. A is restricted to crashes and progression breaks. B is still a high issue that will negatively affect the consumer's experience withe the product. C is a minor issue that will only moderately affect the consumer's experience. And D which is usually reserved for suggestions and the most minor of issues.

3. Assign

Usually the task of a QA Lead or a Producer, the issue will first be read to see if it is something that needs to be fixed. If the manager decides that the issue shouldn't be fixed at all, it will be closed and sent back to the QA team. If it does need to be fixed, the manager will prioritize the issue (just like any other dev task) based on the classification and other info given in the report and will assign it to a developer to be fixed/addressed.

4. Fix

Once assigned and depending on the bug's priority, a developer will attempt to resolve the issue described in the report. Please note that in quality assurance, a fix is only attempted and worked on. It is not EVER confirmed fixed at this stage. This is a very common mistake studios large and small make and it always allows issues to remain unaddressed for long periods of time, messing with the project schedule and causing headaches for all involved.

5. Regress

By far the most important step in the lifecycle of a bug, regressing an issue means to attempt to reproduce a bug after a fix has been applied to it. If the issue can no longer be reproduced, the issue is indeed proven to be fixed and can be closed out by the QA team. However if the fix failed and the issue is still reproducible, it will remain open and be sent back to the developer who applied the fix explaining what happened. Please note that in order to keep the pipeline functioning smoothly, besides a manager choosing not to fix an issue, this is the only way it can be closed. And always the final determination is made by the QA team (with input from other leads if necessary) on whether or not the issue is truly fixed and can be closed out.

I hope this introduction to the QA pipeline helps you with understanding the basic model that most studios use (at least in my experience) for testing games. Know that even if your team consists of only 3 people with absolutely no QA team to speak of, this process can still work provided it is adhered to and adjusted as needed. Please feel free to leave me some feedback and let me know what you think!