how i connected these two entities in my life

Hello everyone! My name is Andrey, I am a quality assurance expert at t2. I want to tell you my story about how, while studying the profession of a QA engineer on the Internet and playing board games with friends, I got a job as an auto tester and sold my first board game.

The article is intended for all people interested in board games (from beginners to experienced players and authors) and the IT sphere: from testers to game developers.

From SEO to QA and Desktop Gamedev

For a long time, I worked as an SEO optimizer and in my free time I studied Java and played board games. I applied the skills I acquired from Java in the SEO profession, in particular, I wrote scripts in Selenium to quickly perform regression when changing the site. Later, I learned that there is a separate QA profession, namely, an automated tester. I knew the language, but I was not familiar with the theory of testing. On the hh.ru website, I saw an ad about recruitment to the automated testing school from bellintegrator, passed the technical interview on Java core and got into the next stream. While undergoing training, I simultaneously came up with board games with my friends, which we often played, found “bugs” and ways to improve the gameplay, corrected the balance – in general, we tried to make interesting games so that getting together would be even more fun.

By studying the theory of testing, I was able to look at the development/testing of board games from a professional point of view. The approach to game testing became more conscious and disciplined; we already had specific roles, product versioning, features in the form of mechanics, etc. The testing process is described in more detail later in the article. After completing three months of theory and practice on the courses (with a lot of homework and a final exit interview on all the material studied), I received my first offer.

One morning I was riding the tram to work and I had an idea for a simple game called “Cat and Mouse”. I think the name speaks for itself: there are mice that steal cheese and a cat that catches them. I imagined how it might look on a table, added elements like rooms where mice could hide and be caught, sketched out abstract rules, then combed them in more detail by phases, player actions, thought out the winning conditions for both sides and suggested that my friends get together to play. The game turned out to be easy, but at the same time exciting, you wanted to play it again and again. At that time, I already had several games in development, and I was planning to go to “Granikon” (a convention of board game developers) in St. Petersburg when I finished one of them. “Cat and Mouse” was an almost finished, tested product that I was not ashamed to present. On the website https:/grani.games/ I posted a short description of the game idea and a rough draft. The prototype needed some work, so we continued playing, simplifying the rules, balancing and tweaking the details.

One fine day, I received an email notification from the children's board game development studio KONIK GAMES, a new division of the large wholesale company “Konik”. They launched the development of their own board games, including development and production, and were looking for interesting projects. The editor-in-chief, Polina Oreshnikova, contacted me with a proposal for cooperation. Later, she supervised the project from the idea to printing. I can say from personal experience that the interaction process is very professional, everyone hears each other, and the voice of both parties is taken into account at all stages of development. As a result, we got a product that suits everyone. So, my project “Cat and Mouse” interested the editor of KONIK GAMES, and we began working together. I prepared a concept and sent a prototype with the current rules and course of the game.

Since there are already hundreds of cat and mouse games on the market, the editor suggested a new setting and lore (game background): an American house from the 70s, where a gang of raccoons breaks in to look for food, and the owner catches them and sends them to the backyard. In this case, changing the setting played a decisive role, because the theme and visuals are important components of success. The concept of the updated version, called “Raccoon Gang”, was presented to the management along with other games and selected for further work. After the project was approved, I received positive feedback and an offer to conclude a purchase and sale agreement with the transfer of copyright.

We were in regular contact with the guys from KONIK GAMES. They, like me and co-authors Ivan Azarovsky and Alexey Borisov, who helped me test the game, put their hearts into this project. A whole creative team worked on the game: the CEO, the head of the studio, the production editor, the artist, the designer, the proofreader, the layout designer, and the children for whom it was created. The editors tested the prototype of “The Raccoon Gang” at an after-school program in an elementary school. A special reason for joy was that the children were brought several different games, and the “raccoons” were especially popular. Most of all, they liked to play for the owner and catch raccoons.

The key moment for me was the involvement of an experienced developer and expert in the world of board games, Yuri Yamshchikov, in the project. He was the project developer, worked on mechanics and balance, and made a significant contribution to the development of the game: his first proposals for reducing phases turned out to be constructive and made the game much easier.

Development process

Our further work was within the framework of a certain SCRUM, the project was divided into short development cycles: we supplemented and updated the existing version of the game, customers made changes to the rules, tweaked the mechanics, conducted internal and external testing and returned with feedback.

The work was divided into 3 stages: concept development, demo version and the final version of the game.

STEP #1
Concept development included the following components:

● general information about the game: name, number of players and time of the game

● game summary (genre, theme and main mechanics)

● game components

● starting layout, telling about the preparatory stage before the start of the game

● game progress with information about phases, gameplay, round completion and player actions

● game features that describe key points or components

● additions from the author.

STEP #2
Demo version – this is a rough draft of the product, namely a prototype of the game that you can already play. As a rule, paper, a pen and some buttons as game tokens are enough (I used tokens from other board games).

STEP #3
The final version of the game – this is a working version of the game in terms of engine and gameplay. The subsequent stages took place without our participation with the co-authors. This is work with an artist on drawing illustrations for the project, editing, proofreading, translation into other languages, rules layout, production and printing.

When the customer had comments and ideas, we made corrections or explained why the suggestions could not be implemented. After revision, we sent an updated version → and so on until the result satisfied all interested parties. We had dailies (daily scrum), where we discussed pressing issues on the topic of balance, interactivity, game mechanics, etc., we had retro or sprint reviews with a demonstration of work.

Application of testing theory in game development

It is funny that software testing tools and approaches in the form of agile methodologies have found application in the field of board game testing. During the development of the game, I used various test design practices from the field of testing. Using one of the rooms as an example, I will tell you how boundary values ​​and equivalence classes were used.

Among the rooms the player could go to was the trap room (the local casino), where raccoon players roll a die that decides their fate: whether they return to their camp with loot or are caught by the owner's traps and sent to the backyard.

“Trap” should feel like something you don't expect, something you can't prepare for in advance, there should be a high risk of getting caught. Simple math divided the value 6 by 3 in the negative direction, namely the chance of getting caught (three to one). In order not to get caught, you need to get one of two values ​​on a six-sided die. Having played enough tabletop role-playing games (D&D) and remembering how pleasant it is to roll high and maximum values ​​on a die, we decided that the numbers for success would be 5 and 6.

The testing of a specific room was carried out by unit testing. Players for raccoons purposefully went to the room with a trap and rolled a dice. It was important to check all the values ​​that came up. Equivalence classes were divided into 2 subclasses: 1-4 and 5-6. For each subclass, we determine a specific value in the range of test data of the class, for example, 2 and 5 or 3 and 6. An integral part of testing any equivalence class is another test design technique – boundary values. Boundary values ​​are a test design technique that expands equivalence classes with additional checks at the boundary of changing conditions. To determine the boundary values, we need to determine which values ​​are the initial and final for our chosen class. It turns out that for our 2 subclasses we have boundary test data: from 1 to 4 and from 5 to 6. The difference between the application of these techniques in the field of board game development and software testing is that it is not the functionality of the feature that is tested, but its balance: how often a certain value will fall out, and how this will affect the gameplay. Adults are aware of the risk and go to the room with traps in very rare cases. An interesting fact is that children have a different perception, they are gambling and go to this room for tests much more often than adults.

The Life Cycle of a Board Game

Developing a board game is a very exciting process, in which it is quite possible and necessary to apply knowledge from the field of software testing. My board game went through all stages of the software life cycle, namely:

1. Research and Analysis. We studied niches based on the gameplay and concept of the game; we decided that this game fits into the category of children's games. In this regard, there was a very specific understanding of the product: the game should not have a pile of mechanics, it is better to allocate no more than 10 minutes to explain the rules, the game itself should be dynamic and fun.

2. Planning. With a clear idea of ​​the target product and the game picture, we begin to plan all the components of the project, the number of cards, chips, victory points, starting hand, move and player capabilities. To stick to the plan, we organized weekly meetings for testing and discussing the gameplay.

3. Design. At this stage, everything is already known to create a project and move on to the next step. In our case, a regular txt file served as a document with rules, and cards and other game components were assembled in figma.

4. Implementation. At the previous stage, we decided how the game should look, and now it's time to print a prototype to be able to play and test the game. We printed cards with text on a regular printer, and cubes and other tokens for indicating victory points, meeples, etc. were borrowed from other board games.

5. Testing and integration. Various types of testing are used here, namely:
● Functional testing
Testing of game mechanics, variability of player actions, balance, game phases and victory conditions. The game rules served as documentation and requirements, and were changed and improved during testing.
● Regression testing
The same tests were already conducted according to agreed, established rules with new implementations that, in our opinion, should improve the gameplay. If new implementations made the game difficult, unbalanced, loaded or uninteresting, the new feature was not introduced. Then it was either improved or simply removed.
● Performance testing
This stage can be renamed as replayability testing. The point is how many times you can play the same game while maintaining interest and motivation to play it again, and how many unique and interesting situations occur during the games. If the player has many options for starting the game, which as a result leads to interesting, unique events that differ from previous games over dozens of games, then replayability testing can be considered successfully completed.
● Integration testing or target audience testing
This is a key stage, it defines the integration of interaction between children and adults, adults with adults and, most importantly, children with each other. We played “Raccoon Gang” with our younger brothers, KONIK GAMES editors went to schools and played with children, explained the rules and watched how second-graders played themselves. Here you can add a sub-stage – “Testing the user experience” – observe the actions of children, what is easy or difficult for them to do, uncomfortable, whether everything is clear to them.

6. Deployment and Maintenance

Our joint work with the customer ends when there is an approved final version of the game prototype and rules + a certificate of completion. Then the publisher moves on to the next stages: drawing the project with an illustrator, translating the rules into other languages, layout of the layouts, design and production of the board game print run.

7 principles of testing in gamedev

While developing the game, I followed 7 principles of testing, which, surprisingly, turned out to be absolutely applicable to testing board games. So:

Principle #1: Exhaustive testing is impossible. A good board game is a game that was stopped testing in time. There must be a finish line in board game testing. A huge number of tests and innovations can lead to the game being oversaturated with details, unnecessary mechanics, game phases and player move options, which in turn will make it complex, incomprehensible and overloaded.

Principle #2: testing demonstrates the presence of defects, not their absence. Testing a board game can reveal bugs, but it cannot fully prove that there are no defects. The desire to test EVERYTHING will lead to the problems from the previous point.

Principle #3: The No-Error Fallacy. During testing, you can find as many errors as you want: find an imbalance or identify a complex gameplay process, which will allow you to optimize the game. It is impossible to determine all the outcomes of events and all options for game actions and bring the game to perfection, the concept of perfection is elastic and different for everyone. During testing, you can identify the most frequent and possible cases. The goal of testing a board game is to find critical defects that break the gameplay. Identifying and fixing non-trivial defects can delay the process of testing and developing a board game.

Principle #4: Early testing saves time and money. It's simple here, before printing a board game for store shelves, you need to play it dozens of times and it's better to identify problems at this pre-press stage. Correcting a defect is expensive, because it's necessary to reprint the entire print run, and a game with defects carries reputational risks for the company, which will negatively affect future game releases.

Principle #5: The principle of accumulation or clustering of defects, or the Pareto Principle. It is necessary to identify the so-called “heir of problems” in the game. If the game has defects, try to identify the main module of the problem. Is the game unbalanced in scoring? Instead of managing and determining how many points are needed to win, try to reconsider the possibilities of obtaining them; maybe some game element brings too many victory points or, on the contrary, too few? The rule is that 80% of defects are localized in 20% of the module. Simply put, it makes sense to recheck the most basic elements on which the game is based.

Principle #6: Testing is context-sensitive. Here it is enough to define the target audience. Children will play a children's board game, they do not need a rulebook with 20 pages of rules or a huge box with an insane number of game elements, children do not need a 15-minute layout of the game before the game. A children's board game should be fast, simple and fun. This testing principle is also applied to other genres of board games for audiences of any other age segment. It is easier to test a game if you know who will play it.

Principle #7: The Pesticide Paradox. The same tests with the same people stop revealing errors. It is necessary to change roles; in the raccoon example, the same person should play both the raccoon and the owner. It is also necessary to change the conditions of the game: play with other people, provide other people with the opportunity to play without your participation. What you do not notice, another person may notice, and an outside perspective is always useful. I myself encountered a similar problem when I was developing and testing another board game with the same people for a long time. When it seemed to me that the game was tested and could be released, I registered the project on the website https:/grani.games/designed the concept and prepared a prototype. After the project was approved by the moderators, a time slot and a table for demonstration were registered on one of the convention dates, I bought a ticket to St. Petersburg and came with my prototype to demonstrate the game at Granicon. Watching from the sidelines as people played my prototype, commenting on the gameplay and explaining the rules, I noticed that no one understood the game, as it was overloaded with mechanics, tablet ergonomics, player actions, the number of phases and game elements, although the game was meant to be a filler (a quick game for 10-15 minutes, which is usually played to warm up before a serious board game for 40+ minutes). We defined the target audience, but we made the game not for them, but for ourselves. Therefore, it is important to test the game with different people: go to game libraries, anti-cafes, GRANI guild cells, send your game to bloggers who review games, play them, etc.

Sources of inspiration

The board game “Alien Planet” (2016) inspired me to create the children's game, namely the “one against all” genre and the layout of locations on the field where players can move. In “Alien Planet”, the movement takes place on an unknown land of deep space, the players take on the role of space travelers, and one of the players is the owner of the planet. In “Raccoon Gang”, the action takes place in a house, and all movement takes place on its territory. Some players wandering around the house did not seem enough, so I added an NPC (Non-player character), namely a random in the form of a cube, thereby creating a kind of artificial intelligence. The cube was responsible for the movement of the dog, a specific number – for a certain room in the house; at the beginning of the game, the player as the owner rolled the cube and moved the dog to the appropriate place, this place was blocked for the players, thereby narrowing the choice of rooms.

Another source of inspiration for me was the steampunk game Mission: Red Planet (2015), where players need to colonize Mars by boarding a rocket with meeples. The spaceship was filled with player character cards, which were played face down, since the main mechanics of the game are hidden roles. I liked the character card play phase because no one knew who exactly each player would play, each character has unique properties that allow you to fill the ships with passengers, and the most interesting thing is that the number of places on the rockets was limited. In order to accurately get on the ship, it was necessary to correctly read the actions of other players, namely, to understand which character they will play. How does the gameplay work in Raccoon Gang? The player for the host chooses one of the location cards for an ambush face down, and the player for the raccoons places any number of their figures on the raid card opposite the room they decided to go to. The owner needs to guess the raccoons' intentions in advance and hide in such a way as to disrupt their grandiose plans.

To sum it up

The experience of creating a board game allowed me to broaden my horizons, look at the profession of a QA engineer from a different angle and apply my professional skills as a software tester in the field of board game development.

“Raccoon Gang” is a one-versus-all card game for kids aged 8 and up. The game takes 20 minutes. There is bluffing, closed drafting and guessing. Each round, the host plays one of five location cards. He must set up an ambush, catch the raccoons and send them to the backyard. The raccoons must act carefully to avoid being caught by the host, get 8 food tokens and leave uncaught. There may be a guard dog and a trap in any location.

This board game can be called a family game, it is interesting to play for both children and adults. The game was released in Russian, Azerbaijani, Kazakh, Belarusian and Armenian languages, and it can already be purchased in stores and on marketplaces.

This is the story from idea to implementation 🙂