QA in slot development: how it differs from regular testing

There is one simple interview question that instantly reveals whether a candidate has ever tested games: “A player loses their internet connection while the reels are spinning. What should happen?”

The right answer: nothing bad. The round has already been settled on the server, and when the player comes back they must see the same outcome and receive the same money. Testing that scenario is one of the first things a new slot QA learns — and one you will not find in any testing course.

What actually makes it different from regular QA

The toolkit is formally identical: test cases, Jira, Playwright, Postman, SQL. The difference is the cost of a mistake and what even counts as a bug.

In an ordinary product a bug means the user cannot complete an action. In a slot a bug means the money was calculated differently from what the game rules promise, or the round result could not be reproduced. The first costs the company payouts and reputation; the second costs a rejection from the certification lab and a release pushed back by weeks.

Hence the main shift in mindset. Slot QA clicks buttons less and reconciles numbers more: the balance before and after the spin, the entry in round history, the wallet transaction and the server log — everything has to match to the cent.

What a QA engineer in a studio actually tests

• The game round and its recovery. Dropped connection, closed tab, a phone dying in the middle of a bonus game. The classic test is to kill the session at every phase of the round and confirm the state is restored on return.
• Calculations and the paytable. Every winning line, every multiplier, all the edge combinations. Checked against the mathematician's document, not against “looks about right”.
• Bonus mechanics. Free spins, bonus buy, collect features, jackpots. More than half of all bugs live here: state accumulates between spins and the logic breaks on non-standard transitions.
• Wallet and limits. A bet above the balance, a parallel session in two tabs, a transaction cancelled on the platform side, fractional currencies.
• Responsible gaming. Deposit and bet limits, time-outs, self-exclusion, mandatory reality checks. In some jurisdictions these are blocking requirements covered by a separate checklist — the same logic as in the operator's compliance department, but at the level of the game code.
• Localisations and currencies. A single game ships in 15–30 languages. You check not just the translation but text truncation, number formats and sometimes words and symbols banned in a specific country.
• Compatibility. Slots are mostly played on phones, often weak ones on a bad connection — the device matrix here is longer than in corporate products.

Certification: the part other QA jobs do not have

Before a game reaches operator sites it is checked by an independent lab — GLI, BMM, eCOGRA, iTech Labs. They verify the random number generator, whether the actual RTP matches the declared one, behaviour during failures and compliance with a specific jurisdiction's rules.

QA is the one who prepares the build and the document package for that review: mechanics descriptions, game rules, test run reports, evidence that the round recovers. A rejection from the lab costs the studio money and wrecks the release calendar, so “how many certifications passed first time” is a real KPI they will quote at your interview.

There is an extra complication: the same game is built differently for different markets. In one place bonus buy is banned, in another the maximum bet is capped, in a third a session timer is mandatory. So regression runs not once but as many times as there are jurisdictions — which is exactly why studios value automation engineers so highly.

A day in the life

What you need to know

1. Test design. The core skill, more important here than tools: a game is a state machine with money in it, and it has to be covered systematically, not at random.
2. SQL. Half of all checks are a database query: did the transaction settle, what is recorded in round history, does the balance match.
3. API testing. The game client only draws; the truth is in the server responses, so Postman and REST are daily tools.
4. Automation. Playwright, Cypress or Selenium on the UI plus the API layer. Automation engineers earn a grade above manual testers.
5. Basic grasp of probability. You do not need to be a game mathematician, but you will have to tell a statistical deviation on a short run from a genuine calculation bug.
6. English B1+. Lab documentation, correspondence with the operator and internal specs are all in English.

What QA pays in iGaming

Ranges are fixed net monthly pay, based on the section of professions and salaries at SpinHire. “Malta / Cyprus” means office and hybrid teams at studios and operators, “EU” means Poland, Romania and the Baltics, “remote” means Tbilisi, Yerevan, Kyiv and fully distributed teams.

The annual bonus in QA is more modest than in marketing: usually 5–12% of the annual base, sometimes release bonuses in studios. In exchange the range is stable and barely depends on whether the operator had a good month — unlike a media buyer on profit share.

What genuinely moves the range up: automation (+20–35% over the manual grade, all else equal), experience supporting certification and an understanding of the payments side. For comparison, a platform backend developer at the same grade costs about a third more — a reasonable benchmark if you are planning a move into development.

How to break into the profession

Manual QA is one of the most accessible ways into iGaming, alongside support. Studios and platforms regularly hire testers with no gambling experience, because domain knowledge really can be picked up in a couple of months — meticulousness cannot.

1. From QA in any other industry. The most common route, usually without losing a grade. Fintech and e-commerce are valued especially: the habit of handling money in a system and of idempotency is already there.
2. From game development outside gambling. You already understand game mechanics and the device matrix; what you add is RTP, certification and jurisdiction requirements.
3. From scratch into manual game testing. A real but narrow path: competition for junior roles is high, and the requirements are English, care and the ability to describe a bug clearly. Other ways in are covered in our piece on getting into iGaming with no experience.
4. From support inside the company. A support agent sees bugs first and knows the product better than most. An internal move into QA after a year is an ordinary story at operators.

What to put in your CV: the types of products you tested, automation tools with the stack named, your SQL level, experience with payment or financial calculations. If there is no gambling in your history, state plainly which money scenarios you tested in your previous product. That converts into an interview better than an ISTQB certificate.

Where to grow next

The vertical is short: QA → Senior QA → QA Lead → QA Manager / Head of Quality. Beyond that it is either running quality for the whole studio or moving into adjacent roles.

Horizontal routes out of QA work better in iGaming than in most industries, because a tester gets to touch everything at once: product, payments, maths and regulatory requirements. The most common moves are into development via automation, into product management, into analytics and into compliance.

The last one is not obvious but it is logical: someone who spent years testing responsible gaming limits already knows half of what the compliance department does.

Open roles at studios and platforms are in the game development section, and the full career profile with responsibilities, KPIs and tools sits on the QA engineer page. Every job in the industry with a stated salary range is on the SpinHire board.