Technical Aspects of Game Test Automation

Test automation always ahs been a lucrative way of reducing the monotonous burden on the tester. But beyond the standard incentives for test automation, sometimes automation can become almost imperative for certain kind of games. The obligation of automation is explained below:
  • Game Speed : Sometimes, the game is to played at very high speed (say hardest level or fastest mode), which can be achieved only after a certain level of skill and experience with that particular genre of games. In this case, the tester must either spend hours in becoming master of a game, or resort to some automation technique.
  • Game Complexity : Game play may become quite complex and the user may not be sure about the next move. This happens in planning games (ranging from Chess to Lemonade Tycoon), luck games (like card games) and in almost all multi-level games after more complex levels are reached. Again, the tester must either spend hours in becoming master of a game, or resort to some automation technique.
  • Multiple Builds : In any commercial software – more so in games – the developer may give several builds (versions) of the game before the final market-ready build. The initial builds have several flaws (popularly called as BUGS), which are progressively removed in further builds. Every time, a similar suite of test cases has to be executed and the automation of this suite can pay rich dividends in the long run. In the current Game Testing project done by the team, some thirty-six different file versions of the game have been tested for nine consecutive builds, with minor modifications. Thus, a few extra efforts done for making automation on the first build, result in substantial saving of time and efforts later.
  • Time/Logic Constraint : Games may need a long sequence of moves to attain completion. A classic example would be the card games like Solitaire. In such games, the tester would have to expend a lot of time to reach the end-game scenario. Secondly, the tester would have to continually apply logic for making the right moves. So his efforts are directed at playing the moves, rather than testing the game behavior. Here automation can play wonders, by handling the game moves and leaving the tester free to focus on the other aspects. (We will see the way to manage this later)
  • Load Simulation : For multiplayer games, the tester would have to manually load the game across several platforms or use network techniques to simulate the multiplayer situation. Either way, a lot of efforts are required and still the conditions are not adequately simulated. Testing tools can provide the multi-user simulation easily.
  • Scenario Simulation : A classical problem in game testing is when the user suspects a bug in some peculiar game scenario, but is unable to reach that particular stage easily. Suppose you believe that the transition between given levels causes a problem if some other control parameter has a particular state(Imagine that you want to see the transition from 12th to 13th level when the game character has its last life). The situation becomes also arises in case the game algorithm is already proven, and the current focus is on game experience (UI and performance verification). The tester has no desire to play the game moves, but is forced to do so, just to reach the desired stage. A testing tool, correctly programmed can provide the scenario simulation easily.
Don't miss any article:Get it by E-mail