QA w produkcji slotów: czym różni się od zwykłego testowania

Jest proste pytanie, po którym na rozmowie w studiu slotów od razu widać, czy ktoś testował gry: „Gracz stracił internet dokładnie w momencie, gdy bębny się kręcą. Co powinno się stać?”

Prawidłowa odpowiedź: nic złego. Runda została już rozliczona na serwerze, więc po powrocie gracz musi zobaczyć ten sam wynik i dostać te same pieniądze. Sprawdzenie tego scenariusza to jedna z pierwszych rzeczy, których uczy się nowy QA w studiu slotów — i jedna z tych, których nie ma w żadnym kursie testowania.

Na czym właściwie polega różnica wobec zwykłego QA

Formalnie narzędzia są te same: przypadki testowe, Jira, Playwright, Postman, SQL. Różnica tkwi w koszcie błędu i w tym, co w ogóle uznaje się za buga.

W zwykłym produkcie bug to sytuacja, w której użytkownik nie może wykonać akcji. W slocie bug to sytuacja, w której pieniądze policzono inaczej, niż obiecują zasady gry, albo w której nie udało się odtworzyć wyniku rundy. Pierwsze kosztuje firmę wypłaty i reputację, drugie — odrzucenie przez laboratorium certyfikujące i przesunięcie premiery o tygodnie.

Stąd główna zmiana w sposobie myślenia. QA w slotach mniej klika w przyciski, a więcej uzgadnia liczby: saldo przed spinem i po nim, wpis w historii rund, transakcję w portfelu i log serwera — wszystko musi się zgadzać co do centa.

Co konkretnie testuje inżynier QA w studiu

• Rundę gry i jej odtworzenie. Zerwane połączenie, zamknięta karta, rozładowany telefon w środku gry bonusowej. Klasyczny test to zabicie sesji w każdej fazie rundy i sprawdzenie, że po powrocie stan został odtworzony.
• Obliczenia i tabelę wypłat. Każda linia wygrywająca, każdy mnożnik, wszystkie skrajne kombinacje. Porównuje się z dokumentem matematyka, a nie z „na oko wygląda dobrze”.
• Mechaniki bonusowe. Darmowe spiny, zakup bonusu, funkcje zbierające, jackpoty. Tu mieszka ponad połowa błędów: stan kumuluje się między spinami, a logika psuje się przy nietypowych przejściach.
• Portfel i limity. Zakład wyższy niż saldo, równoległa sesja w dwóch kartach, anulowanie transakcji po stronie platformy, waluty ułamkowe.
• Odpowiedzialną grę. Limity depozytu i zakładu, przerwy, samowykluczenie, obowiązkowe przypomnienia o czasie gry. W części jurysdykcji są to wymogi blokujące, sprawdzane osobną listą kontrolną — ta sama logika co w dziale compliance operatora, ale na poziomie kodu gry.
• Lokalizacje i waluty. Jedna gra wychodzi w 15–30 językach. Sprawdza się nie tylko tłumaczenie, lecz także ucinanie tekstu, formaty liczb, a czasem słowa i symbole zakazane w konkretnym kraju.
• Zgodność. W sloty gra się głównie z telefonu, często słabego i przy kiepskim zasięgu — macierz urządzeń jest tu dłuższa niż w produktach korporacyjnych.

Certyfikacja: to, czego nie ma w innym QA

Zanim gra trafi na strony operatorów, sprawdza ją niezależne laboratorium — GLI, BMM, eCOGRA, iTech Labs. Weryfikują generator liczb losowych, zgodność faktycznego RTP z deklarowanym, zachowanie przy awariach i przestrzeganie zasad konkretnej jurysdykcji.

To QA przygotowuje build i pakiet dokumentów do tej weryfikacji: opis mechanik, zasady gry, raporty z przebiegów, dowody na to, że runda się odtwarza. Odrzucenie przez laboratorium kosztuje studio pieniądze i rozwala kalendarz premier, dlatego „ile certyfikacji przeszło za pierwszym razem” to realne KPI, które usłyszysz na rozmowie.

Osobna trudność: ta sama gra na różne rynki budowana jest inaczej. Gdzieś zakazany jest zakup bonusu, gdzieś ograniczona maksymalna stawka, gdzieś obowiązkowy jest licznik czasu sesji. Regresję przechodzi się więc nie raz, lecz tyle razy, ile jest jurysdykcji — i właśnie dlatego studia tak cenią automatyzację.

Dzień z życia

Co trzeba umieć

1. Projektowanie testów. Podstawowa umiejętność, ważniejsza tu niż narzędzia: gra to automat skończony z pieniędzmi w środku i trzeba go pokrywać systemowo, a nie na wyczucie.
2. SQL. Połowa sprawdzeń to zapytanie do bazy: czy transakcja się zgadza, co zapisano w historii rund, czy saldo się zgadza.
3. Testowanie API. Klient gry tylko rysuje; cała prawda jest w odpowiedziach serwera, więc Postman i REST to codzienne narzędzia.
4. Automatyzacja. Playwright, Cypress lub Selenium na UI plus warstwa API. To automatycy zarabiają o grade więcej niż testerzy manualni.
5. Podstawy rachunku prawdopodobieństwa. Nie musisz być matematykiem gier, ale odróżnić odchylenie statystyczne na krótkim przebiegu od prawdziwego błędu w obliczeniach będziesz musiał.
6. Angielski B1+. Dokumentacja laboratoriów, korespondencja z operatorem i wewnętrzne specyfikacje są po angielsku.

Ile zarabia QA w iGamingu

Widełki to stała pensja netto miesięcznie, według sekcja Zawody i wynagrodzenia SpinHire. „Malta / Cypr” to zespoły biurowe i hybrydowe studiów i operatorów, „UE” to Polska, Rumunia i Bałtyki, „zdalnie” to Tbilisi, Erywań, Kijów i zespoły w pełni rozproszone.

Roczny bonus w QA jest skromniejszy niż w marketingu: zwykle 5–12% rocznej podstawy, czasem premie za premierę w studiach. Za to widełki są stabilne i prawie nie zależą od tego, czy miesiąc był dla operatora udany — inaczej niż u media buyera z procentem od zysku.

Co realnie podnosi widełki: automatyzacja (+20–35% wobec grade’u manualnego przy pozostałych warunkach równych), doświadczenie w prowadzeniu certyfikacji i rozumienie części płatniczej. Dla porównania, backend developer platformy na tym samym grade kosztuje mniej więcej o jedną trzecią więcej — to rozsądny punkt odniesienia, jeśli planujesz przejście do developmentu.

Jak wejść do zawodu

Manual QA to jedno z najbardziej dostępnych wejść do iGamingu, obok supportu. Studia i platformy regularnie zatrudniają testerów bez doświadczenia w hazardzie, bo wiedzy branżowej naprawdę można douczyć się w kilka miesięcy, a skrupulatności — nie.

1. Z QA w dowolnej innej branży. Najczęstsza droga, zwykle bez utraty grade’u. Fintech i e-commerce są cenione szczególnie: jest tam już nawyk pracy z pieniędzmi w systemie i z idempotencją.
2. Z gamedevu poza hazardem. Rozumienie mechanik gier i macierzy urządzeń już masz, douczyć trzeba RTP, certyfikację i wymogi jurysdykcji.
3. Od zera na manualne testowanie gier. Realna, ale wąska ścieżka: konkurencja na stanowiska juniorskie jest duża, a wymagania to angielski, staranność i umiejętność zrozumiałego opisania buga. Inne warianty wejścia omawiamy w tekście o pracy w iGamingu bez doświadczenia.
4. Z supportu wewnątrz firmy. Agent supportu widzi bugi jako pierwszy i zna produkt lepiej niż wielu. Wewnętrzne przejście do QA po roku pracy to u operatorów zwyczajna historia.

Co wpisać w CV: typy testowanych produktów, narzędzia automatyzacji z nazwanym stackiem, poziom SQL, doświadczenie z rozliczeniami płatniczymi lub finansowymi. Jeśli nie było hazardu w doświadczeniu, napisz wprost, jakie scenariusze z pieniędzmi sprawdzałeś w poprzednim produkcie. To konwertuje na zaproszenie lepiej niż certyfikat ISTQB.

Dokąd rosnąć dalej

Ścieżka pionowa jest krótka: QA → Senior QA → QA Lead → QA Manager / Head of Quality. Dalej albo zarządzanie jakością całego studia, albo przejście do ról pokrewnych.

Ścieżki poziome z QA działają w iGamingu lepiej niż w większości branż, bo tester dotyka wszystkiego naraz: produktu, płatności, matematyki i wymogów regulatorów. Najczęstsze przejścia to development przez automatyzację, product management, analityka i compliance.

To ostatnie nie jest oczywiste, ale logiczne: ktoś, kto latami sprawdzał limity odpowiedzialnej gry, zna już połowę pracy działu compliance.

Otwarte oferty w studiach i na platformach znajdziesz w dziale produkcji gier, a pełna karta zawodu z obowiązkami, KPI i narzędziami czeka na stronie inżyniera QA. Wszystkie oferty branży z podanymi widełkami są na tablicy SpinHire.