Any gambler probably knows that a slot machine is sometimes jokingly referred to as “the one-armed bandit.” When they were first created, slot machines were mechanical devices containing reels wound on large metal hoops that were connected to a lever on the side—players pulled this “arm” to activate the machine, and they were usually left considerably lighter of pocket.
Today, these mechanical parts have been replaced by software. A math engine generates a random array of symbols on the screen, winning combinations are assessed, and the winnings are paid out.
As you can imagine, working with a program that creates random outcomes like this poses some interesting challenges for testers. And because casino gaming falls under the category of e-commerce, all the money flowing through the system is digitally accounted for as per the guidelines of the local regulatory authority. The QA team also has to factor this in while testing, which makes the task even more unusual.
Having worked in this domain, let me share what I know from a tester’s perspective and reveal what it’s like testing slot machines.
How a Slot Machine Works
First, let’s take a good look at a slot machine. It has two monitors, a bill acceptor, a coin acceptor, push buttons, LED lights, a thermal printer, and sometimes a smart card reader. All these parts have a protective casing to prevent interference from static.
Slot machine software, just as with all software, needs to be tested well, and often. Testers use libraries that are part of the game development kit (GDK).
The math engine that randomizes the screen display is the most important part of the GDK. To ensure that a random array of symbols is displayed on the screen and that it is different every time, a simple computer program would not do. It would need parameters to be passed, such as date and time, which would limit the scope of randomization. The math engine, however, can generate random numbers without needing set parameters.
When the player pushes the button to start the game, the math engine determines how many times and with what velocity the reel would need to rotate. It generates random numbers for each reel to be displayed on the screen. The sequence of images on each reel remains the same; it is only the position of the images on the screen that is randomized and displayed as an array. For each number that is generated, there is a .jpg file in a folder. The game kit picks up the image and sends it to the application kit, which displays it on the screen using the video kit.
Testing Random Outcomes
For testing purposes, the QA team has a layer of software that allows us to request a specific pay table—the list of possible payouts for each combination of symbols.
We ensured that all parameters, such as date and time, would be the same in multiple spins by running the library from the command line using a wrapper, with the output printed on the console. We would run the command for the same parameters multiple times, and the results would be stored in a .csv file. We would then compare the results of these multiple runs to see how often the output was the same. This defined the probability of the outcome, which would then be validated as per the design.