With a product as complex as a casino slot, the physical appearance, functionality and underlying math model needs to be exactly right. Today we pay another visit to the iGaming development process, focusing on the critical task of Testing.

From design and deciding the theme, to art creation, animation and then front-end and back-end development – we have now arrived at the final stop of the production side of the iGaming development process. If you want to refresh what goes into the first five stops of producing a casino slot, links to all those calendar entries are in the box to the right. The next and final calendar entry focuses on stops seven and eight – content creation and publication. But let’s not get ahead of ourselves! One major thing to cover first, the crucial task of testing. At Gaming Corps we have a two person team responsible for Testing and Quality Assurance.

When the processes of design, art and animation have reached their completion, the concept artist and the animator uploads all the assets for coding and the work of the front-end developer starts. After approximately two weeks of front-end development, the game will be in a state where it is possible to start testing. At this point, a lot of the art and animation will be temporary or not yet in place, and key components are a long way and many iterative rounds of discussion, creation and coding away from finished. But the bone structure is there, meaning that most basic mechanics are coded and the math model is up and running, which means that testing can commence. Since every single part of the game has to be tested and retested, the team in charge of testing and quality assurance needs a sizeable period of time to carry out their work.

We asked one of our testers Spiros Logothetis what a normal day at work looks like for him. He answered that it has to start with coffee, and that does make sense! Because for the testers there are very intense periods around the launch of a game. Spiros calls them the “hot days” – leading up to and just after the launch when every small detail needs tending to, and where activating a game in a live environment will result in additional needs for testing and being on call. But, at the start of a project the testers have a calmer work situation, and their work is highly structured throughout the process in terms of routines, templates and documentation. For the most part the testers know what to do and are not taken by surprise with unexpected things, they systematically move through the game. The development team and the test team have a short meeting every morning, a “stand-up meeting” or scrum type of meeting where they cover what they did yesterday, what they will do today and if they have bumped into any blockers. Key ingredients in the daily work of a tester are reports and tickets. In a program called Confluence, the testers compile reports which outline all the tests run and what they deem needed in terms of action. Reports are available to the entire team. These reports are updated as the work progresses, adjustments made added in, everything in chronological order. A specific action, such as “Fix the coding on the third reel which blinks when stopping” is described and analyzed in the report, and then also entered into a program called Jira as a numbered ticket. The ticket is for the developer to pick up as a work order, and when the bug or improvement suggestion is tended to, the ticket is complete. This enables the project manager to have an overview of all the tasks that have to be completed by the developers so that scheduling can be adapted accordingly.

The testers are in close contact not just with the developers on a daily basis, but also with the concept artist and the animator. They need to repeatedly check so that the outcome of the coding aligns with the vision of the artist. Spiros will always start a project by studying all the uploaded art and animation assets to get a good understanding of the theme and the vision, but there is still the need for continuous dialogue to get every detail right. Since the testers have the perspective of the player, they can also come up with suggestions on how to modify art, animation or coding to improve player experience.

Spiros works for the most part with two kinds of testing procedures: daily testing and general testing. General testing is when the entire game is run through, which is time consuming and can’t be done every day. Daily testing is the follow up on what happened yesterday; a new feature was added, an animation was changed, a bug report ticket tended to. Then Spiros will test in various ways to check this specific action.

Testing can be done widely and randomly – with the help of a program the game is run through a certain number of times to check for anomalies. The tester can also use a cheat code and for instance force the bonus game in order to check something specific in there, or force the game to land on a certain combination of symbols to check that. The tester sometimes goes into the code to audit something a very specific, here they don’t alter anything, only access it temporarily and from there simulate an action to analyze the outcome.

Sometimes a bug does not appear every spin or even every 100th spin, but it does appear. The testers can use programs like for instance Selenium – an automation testing program where they can enter a cheat code or set the program to test the game in some other way, which will then be done repeatedly over the course of many hours or a day. If and when the game has a malfunction of any kind, the program automatically takes a screenshot and from there the tester can investigate further.

Casino slots are tricky games in that they can behave very differently depending on the device they are played on. Whether it is a desk top computer, a phone, a tablet and depending on brand, age, browser program etc., the game can work perfectly or have major bugs. The list of devices someone can possibly play our games on is almost endless. So part of the tester’s job is to anticipate all these different needs and test accordingly. A way to expedite that process is using programs like BrowserStacks where one can simulate different devices. This is not 100% accurate as nothing can replace physical testing on an actual device, but helpful when narrowing things down. Spiros always makes sure to do physical testing regularly like an end user would play, on two leading phone brands, on desktops and tablets.

The test and quality assurance team works on 2-3 games at the time, trying to reserve a few days at a time with one game to keep focus. Since the games are in different stages of testing, this means they move between different types of tasks and need to be in contact with almost everyone in the company. The testers have an interesting role as they don’t create or produce the art, the animations, the code, the back-end, the math model or anything that goes into the game. But they probably know the game better than anyone else. And they can deploy a powerful internal/external perspective because of that. Hence they work on identifying problems and solutions to go with them, structure the work of correcting bugs, offer improvements, push the work forward and most importantly take responsibility for the player perspective. The testers are Gaming Corps’ champions for the end users of our products, which is very important.