This is key information and terminology that will be really useful once you’re in the industry. The following are the names and descriptions of different types of testing that game testers do.
*Beta testing is a term that almost everyone knows. Technically, it means any testing that’s done on a game that’s in the “beta” stage of development. Often, though, it means the first version of a game that anyone outside the company sees… a ‘public beta’. Public betas are great because thousands of eager fans will often find bugs that your small group of testers couldn’t. It’s also useful to distinguish beta testers from QA testers: beta testers might test from home, or casually on a single project, while QA testing is generally a full-time, trained job.
*Regression testing is a stage of testing. Once a bug has been fixed by the coders, it’s returned to the QA department for regression testing. QA checks to see whether the bug is still there (regression) and then runs similar tests to see whether the fix broke something else. That second stage is often called halo testing; it involves no space marines, but rather tests all around a bug, looking for other bugs.
*Compatibility testing is one of the geekier kinds of testing, in my opinion: it’s for the hardware mechanics. In order to get the list of system requirements for a game, you need to test it on a bunch of different machines, each with specific video cards, amounts of RAM, operating systems, processors, and so on. You can often start with a good guess (if a game was built for Flash, it has the requirements that Flash does) but you’ve still got to test from there. Compatibility testing pretty much has to come toward the end of development, when the game is coming together, because so much of the compatibility depends on exactly how the programmers work their magic. This means that if you can afford it, it’s often good to run at least two rounds of compatibility tests: one early in beta to highlight some problems with plenty of time to fix them, and one late in beta or during GMC (gold master candidate, when the game is ready to ship) to really figure out exactly what the system requirements are.
*Load testing tests the limits of a system. The system could be the number of players on an MMO server, or the number of sprites active on the screen, the amount of traffic running over an internet connection, or the number of threads running in a particular program. It’s most commonly used in the first sense, to mean the number of players or processes running on a server. Load testing generally requires a lot of people (like a beta test group) or software that fakes heavy activity.
*Unit testing is another pretty technical term, and it may not be the responsibility of the QA department. A unit test is run on a piece of code, often automated, to test whether it works at a basic level. For instance, if a piece of code is supposed to take in a username for an MMO and return an error if the name is already taken, then the unit test would automatically input a name that is known not to be used and one that is used and make sure that the proper response is given. Often programmers write unit tests for their own code, and QA only gets to see that part of the game once it has passed all of its unit tests. A good QA department, though, may help design unit tests to make them rigorous. Unit testing happens throughout a project… anytime the programmers are working!
*Soak testing is a very technical term that will make you look good in interviews but which might land you a tedious job. Soak testing involves running a game for a long time to see whether performance degrades. Very subtle bugs like memory leaks might not come out in playing the game for five minutes but could ruin a saved game or crash the computer after an hour and a half of playing. Soak testing is often automated, with software faking mouseclicks or otherwise making sure the computer doesn’t go to sleep. Many soak test bugs end up being filed unfixed as PUB (”Psychotic User Behavior”, a useful term, really) because a normal player wouldn’t play the same Pac-man level for 175 minutes in a row.