QA101: The 5 Main Stages of Test Process

Are you looking to get started in testing for the gaming industry? Are you a more seasoned quality professional looking to level up your skills? Are you curious to learn more about what testing video games is really like? If you said yes to any the above, then the QA 101 series is for you! We aim to teach the basics of quality assurance by going back to the fundamentals. Each article will contain essential information to explain everything you need to know!

Picture the scene. You’re on the QA team of a big new game project. Development is coming along well and they’ve hired you to help manage the quality of the game. The main question is: what do you test, and how do you test it? The answer is obviously “everything”. This can be such a large and overwhelming task that you must break that down into steps.

The testing process and the strategies used tend to be similar for most titles. But specifics may differ depending on the type of game and the way that the development has been set out. This process isn’t strictly linear and you will likely need to move backwards and forwards throughout the cycle as necessary.

The 5 main stages of the testing process are as follows:

Plan

If we’ve said it once, we’ve said it a million times; QA isn’t about just testing the game. You’ve gotta plan the project strategically. When establishing QA for a new game project, you should outline out the approach(es) that you’re going to take. As mentioned before, this is very similar across all games but will change depending on the scheduling and plans of the development team. For example, you shouldn’t plan to do visual checks in early development as the artwork is likely to have placeholder and non-final textures. You can’t plan to test five levels if the team has only implemented three. The idea of the QA planning stage is to coordinate up with other leaders/producers and understand the current road map. With this information, you can interpret how the QA team can provide the most value.

QA can also feedback into the planned schedule for the game. Advising whether there is going to be enough testing or if there has been enough time scheduled to fix bugs or work on polish is important. It can be difficult to predict this at the start of a project, so revisiting the planning stage often to revise initial estimates is essential.

Design

This is where you begin to fill out the flesh of your plan. It’s all very well to say “run functional tests”, but if you haven’t written these, how do you know what to test & how to test it? How can you tell that tester A does the same type of testing as tester B? You need to have test cases written out. You can plan using the game design document to ensure that you write tests that cover all the features. You can then put these test cases into groupings called test suites. For example, you could group together tests that go over all the weapons. Tests may also be grouped together into suites that address a specific testing need for development. For example, creating a smoke test pass can be used as a daily check that the basic functionality of the game is working as expected. It would contain a wide range of different types of tests at a basic level.

However, the design phase isn’t all about writing tests. You should also lay out the specifics of the testing schedule, create tooling to make testing easier, setting up a bug logging system (like JIRA or Bugzilla), writing automation testing, and so on. The design phase can be revisited many times. This especially true for a long project where writing all the tests upfront doesn’t make sense. Game features may change so you’d either have wasted work, or you’d have to write new tests for content that didn’t initially appear in the GDD.

Implement/Execute

Video Game QA definitely puts a considerable amount of emphasis on running tests cases… Over and over and over! This is the phase that most people think of when they think about QA. This is for good cause as it is given the most time, is the most visible, and the most valuable. Implementing & executing the test plan involves not only testing but all the activities that you planned in the design stage. So you will be writing up bugs, checking through your bug logging system to manage incoming fixes, updating documentation, writing feedback. This is basically all the good stuff that helps make sure that the game is as good as it can be.

Report

The reporting phase of the testing process is where you record and report the quality of the game. How many bugs are you finding? How quickly and accurately are the fixes coming in? Do you feel confident that you’re testing enough? Is there enough time to do the testing necessary? Using all this information, is the game going to be a high enough quality to release on time? Reporting might not seem like a very important part of the process, but it is extremely crucial. Remember, QA isn’t about making sure that a game has zero bugs; it’s about having an accurate measure of exactly what the level of quality is. The development team can then use this information to make decisions on if that is high enough. Reporting is essential in that it allows producers, directors & product managers to make informed decisions about the next steps to take.

Closure

Closure, otherwise known as exit criteria, is the last part of the testing process, but that doesn’t mean the end. It’s often more accurately used to define the completion of the cycle. It makes sure that all of the goals have been addressed. This could either be by having successful test passes or ensuring that any failures have been analysed and attended to. If the current cycle’s goal was to release the game, then the exit criteria would have been to ensure the game does all the things that were defined in the game design document to an acceptable quality level. However, if this cycle was just to mark the end of a milestone in development, you would now revisit the planning stage!

The Testing Process doesn’t have to run linearly from start to finish every time. It’s important to continually check that the work you’re doing is achieving the desired results and if not, to adjust as necessary. This may mean going back to the planning and designing phases multiple times. In the next few articles of the QA 101 series, we’re going to be visiting in more detail how to plan your testing and the creations of test suites & test cases.

Other posts in the QA101 series: