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.
You can adjust your probability of winning by selecting or deselecting pay lines within the pay table, which all have different wagers and wins. In simpler slot machines, wins are decided by the symbols forming vertical, horizontal, or diagonal combinations. But in multiline slot machines, the pay lines could be triangular, oblique, or even zig-zag. The various combinations of pay lines all have unique IDs. The ones selected by the player would be passed to the gaming engine, and from the command line, we would run the gaming library via its wrapper. We would check if the output matched the unique IDs of the selected pay line combinations.
Hardware, Software, and Payments
The QA team also has to confirm that machine payouts are correct. The payback percentage is decided by the casinos, but it has to be above a certain minimum figure, as per the guidelines of the gaming control board. It can be as high as 97 percent of the money that is put into the system. The test team checks thatthe payout is the exact amount given in the functional specifications and that it is the same amount for the same pay line every time.
Every slot machinehas a bill acceptor and a coin acceptor that also need to be tested. In the split second between when a player inserts money into the machine and the amount is displayed on the screen, a lot happens behind the scenes.
At the back end, every slot machine is connected to the gaming authority server of that province. All currency inserted into the slot machines is reported to that server, which then issues a transaction ID and allows the amount to be displayed on the screen. If, for some reason, the ID is not issued, the amount will be refunded, the thermal printer will provide a redeem coupon, and an update will be sent to the gaming authority server. The same thing happens when a player wants to cash out, so all the money that goes into the system is digitally accounted for.
You might have already worked out the potential test cases in this situation. Testers use a dummy server to test for the currency inserted into the machine. Each denomination, whether valid or invalid, is given a unique ID. For instance, a twenty-dollar bill would be assigned, say, the number 511 for an old note (meaning it’s invalid) or 512 for a new note (valid). These IDs are passed to the server, and we observe the slot machine’s behavior. In the case of invalid denominations, the machine should reject the note.
Printing the redeem coupon, updating the server, and smart card validation present more test cases and require physical checks. If a bill gets stuck or the bill stack inside the machine is full, the bill acceptor should push it out. The thermal printer, as a vital part of the workflow, also requires physical verification, such as ensuring the game doesn’t proceed if there is no paper or the paper is jammed.
We also test the screen for the graphics and the sound for the “rollup”: the celebratory music as the meters count the amount for a win. Every game has different LED light combinations and music accompaniment.
Memory Checks and Updates
Any memory that has been used for temporary storage during a program run, if not returned, qualifies for a memory leak. For a program that is run often, this problem can get exacerbated over time, resulting in the termination of the program. We test the slot machine software on a separate computer because we need to run automated commands on the console that would slow down the user experience considerably. We play the game ourselves on this computer while monitoring the process. Our garbage collector library outputs the state of the memory queue to the logs after every instantiation and subsequent deletion of the memory.
For security reasons, there is no provision to update all slot machines from a central server, so when a new game or versions need to be added, the engineer must update each machine manually. This means that safeguards and checks for ID verification of the software engineers must be included in the test plan. Also, before any software can be updated, an encryption code is sent to the gaming authority server for authentication. The test team has to check if any changes in the encryption code would trigger the appropriate safeguards.
Expect the Unexpected
Testing a machine’s ability to create unique, random combinations presents interesting challenges. Throw currency processing into the mix, and you’ve got some intriguing test cases. And as with any QA situation, testing slot machines is not without its surprises.
Once, we were testing three slot machines, and for some inexplicable reason they seemed to be going awry. We racked our brains trying to figure out what could be wrong, until one day, the power failed and we had to work with the uninterruptible power supply. Surprisingly, we faced no glitches that day. Looking around, we saw that there was a power line running directly above the slot machines, and because the top of the machines was made of fiber, they were registering interference from the power line! As with any kind of testing, it’s important to think beyond the obvious.
