In the gaming industry, quality assurance (QA) is entirely focused on finding glitches, bugs and anomalies that exist in the games either during development or in production. QA also includes other activities such as reproducing the issues, documenting them and reviewing the games continuously for the documented issues.
Apart from all of this, sometimes the games would also need to go through fuzz testing or simply fuzzing to find anomalies that usually don't occur during normal usage and require an advanced set of pseudo-random inputs to be given to generate abnormal behaviours during the gameplay. When the games appear to be totally fine for normal usage without any confirmed glitches or anomalies, then they are considered to be good to launch into production.
The Goal of Most Freshers
Let's say you are willing to become a game developer, have no prior development experience, and you are recently graduated. You might be interested to join a game development company at this stage, and you are super excited about your role until you figure out that you aren't going to land a role as a game developer. You will find out that the company is offering you the role of a Quality Assurance Engineer, who handles the activities as mentioned earlier.
The Problem
Sometimes newly hired QA testers or engineers who are aspiring game developers might feel like QA isn't something they need to do. They shall feel like they are being mistreated by the professional game developers, but this isn't the actual case in the gaming industry, which the newly hired people don't seem to understand most of the time, and therefore they feel underestimated and start to neglect their responsibilities. As mentioned before, this isn't simply the case for QA in the gaming industry.
One of the major reasons why such things happen for the newly hired QA engineers is because of the time and effort QA testing takes. Indeed, it requires a lot of time, since it is all about trying out every possible way to carry out different activities during the gameplay, which often increases the permutations when more and more features are added to the games. This is something that most people seem to miss, and the newly hired testers appear to believe that QA testing is all about playing the games as a normal player to figure out if any glitches occur during the game, which obviously isn't the matter of fact. Still, this creates a misunderstanding for these testers that QA testing is treated as something that is disposable and not necessarily essential.
A Real-world Scenario
Let's consider an example here. You are hired as a QA Tester at ABC Games, where they are planning to ship a new game, Game ABC in the market soon, and they require you to figure out the bugs in the game. Now, what most freshers seem to do is, simply playing the game as a normal player, and checking if anything goes wrong while playing the game multiple times, and finding out the bugs there. Over time, these bugs are documented, fixed, and when it comes to performing further testing, testers appear to believe that no other bugs exist in the game. This is because they think other players would play the game in the same way as they did and therefore don't come over any glitches during the gameplays.
Continuing the above example, let's look at a question that might arise! What would happen when Game ABC is launched into production!? Of course, people would download and install the game, and be able to normally play the game without landing over any issues. But, what if they want to make some configuration changes in the game? Would it create any impact on how the game's algorithms work? Since it is already mentioned earlier that the testers wouldn't look into this stuff, their answers would obviously be "No", which is actually wrong. Making some changes to the gameplay might include things like making configuration changes, changing the gameplay modes, or even changing the workflow of applications running in the background that the game might depend upon. So, what would happen due to Game ABC being untested for different gameplay mode changes, background application state changes, configuration changes, and so on? Players would come over so many issues, that shall force ABC Games to issue a public statement or completely disband their newly launched game. As a result of all of these things, the testers might not be able to move up in the company while being a normal QA tester.
The Solution
Looking at all of the things mentioned above, we can obviously come to a point that if someone in a game company handling the role of a QA Tester wants to move up in the company, he/she would certainly need to apply further strategies into their testing workflows. They might prepare a list of all the activities or actions that can be performed in the game, list out all of the different configuration options in the game, and prepare a short informal report consisting of every external factor the game depends upon. With these 3 things in place, the testers might perform different permutations across all of the actions, configurations and dependency states, and come over a long result of many operations that would require testing the game again for every single permutation. This is certainly a tedious task, that becomes too much difficult for a QA Tester to carry out. There are many ways this task can be made easier, such as by bringing fuzzing driven development (FDD) into the game development workflow or implementing automated testing strategies by writing different scripts to automate different actions in the game for each permutation.
We got a hint into how we can make game testing better while performing quality assurance activities from the earlier text, i.e. by applying FDD during game development or by implementing automated testing strategies. We talked about a recently graduated person who wants to become a game developer without any prior development experience, but lands a job as a QA Engineer at a game company at the beginning.