Testautomatisierung: Qualitätssicherung für Casino-Software

Der Abend fing ruhig an. Ein neues Slot-Feature ging live, kleines Hotfix, keine große Sache. Drei Stunden später: Support-Chat rot, Bonus-Guthaben falsch, Auszahlungen blockiert. Fünf Stunden Downtime. Nicht wegen fehlender Tests. Sondern weil der eine Beweis fehlte, der zählt: ein automatisierter Nachweis, dass die Bonus-Regeln unter Last stabil bleiben. Seitdem denke ich anders über Tests. Es geht nicht um „mehr“. Es geht um „richtig“ und „reproduzierbar“.

Warum Glücksspiel-Software anders testet

Webshop-Logik ist linear. Spiele sind es nicht. In Casino-Software treffen Zufall, Geld, Aufsicht und Tempo aufeinander. Wir prüfen nicht nur Buttons und Texte. Wir belegen Fairness, schützen Daten, und liefern Beweise für Prüfer. Und zwar so, dass man sie in sechs Monaten noch findet und neu erzeugen kann.

Der Rahmen ist eng. Die Remote Technical Standards der UK Gambling Commission beschreiben klar, was ein Remote-Spielsystem liefern muss: sichere RNGs, klare RTP-Angaben, robuste Logs, kontrollierte Änderungen. Diese Leitplanken prägen jede Automatisierung, vom RNG-Testlauf bis zum Beleg für ein Audit.

Sechs Fragen, ohne die kein Release durch darf

Gute Qualität ist kein Bauchgefühl. Sie ist ein Set aus Belegen, die ein Team vorlegt. Ich nutze sechs Leitfragen. Jede Frage führt zu Metrik, Tool, Evidenz:

• Belegt das System die Fairness des RNG und die Einhaltung des RTP?
• Halten KYC und Auszahlungswege auch in Randfällen? (z. B. Timeouts, Sonderzeichen, Länderwechsel)
• Bleiben Bonus-Regeln unter Last konsistent? (Stacking, Ablauf, Max-Win)
• Ist Geofencing sauber? Keine falschen Sperren, keine Lücken.
• Greifen Sicherheitskontrollen gegen gängige Angriffe und Fehlkonfigurationen?
• Gibt es klare, versionierte Evidenzen für Auditoren? Reproduzierbar, datiert, nachvollziehbar.

Hilfreich ist ein neutrales Qualitätsbild. Das ISO/IEC 25010 Qualitätsmodell nennt Eigenschaften wie Zuverlässigkeit, Sicherheit, Wartbarkeit. Wir mappen unsere Tests darauf. So sehen Teams, wo Lücken sind. Nicht gefühlt, sondern sichtbar.

Werkbank statt Werkzeugliste: entlang des Spielflusses

Ich starte beim echten Weg eines Spielers. Von Login bis Auszahlung. Dann hänge ich Automatismen an jede sensible Stelle.

Login und Lobby: UI-Tests sind gut, aber nicht allein. Ich kombiniere UI und API. Das UI klickt ein, die API prüft Session, Limits und Feature-Flags. So wird der Test schnell und robust. Für das UI nutze ich gern die Playwright Dokumentation als Basis. Flows mit zwei, drei Schritten reichen oft. Tiefe Checks laufen per API.

RNG und Spielrunden: Der Zufall braucht Statistik, nicht Screenshots. Ich fahre Batch-Läufe mit Millionen Spins. Ich prüfe p‑Werte, Frequenzen, Runs. Die NIST SP 800‑22 Tests für Zufallszahlen sind ein sinnvoller Start. Wichtig sind feste Seeds, gespeicherte Ergebnisse, und Signaturen der Artefakte. Nur so bleibt der Nachweis gültig.

Zahlungen und KYC: Hier helfen Contract-Tests. Wir fixieren, was PSPs und KYC‑Dienste senden und erwarten. Dann testen wir Timeouts, Retries, und Rate Limits in der Pipeline. Keine echten Ausweise, keine echten Karten. Alles mit Mocks, aber realistischen Fehlern.

Feature-Rollout: Flags erlauben schrittweise Freischaltung. Tests prüfen, dass Flags greifen, dass Out-of-Scope Features zu bleiben. Und dass Logs das zeigen.

Fazit: UI‑Only ist zu fragil. UI + API + Batch + Contract = belastbarer Beweis.

Die Kernübersicht: Prüfziel → Metrik → Automatisierung → Tools → Evidenz

Die Tabelle unten dient als Kompass. Sie ist kurz, aber direkt nutzbar. Kopieren, anpassen, in die Pipeline legen. Ein Feld pro Zeile ist Ihr Audit‑Beweis.

Wer Security tiefer prüfen will, nutzt den OWASP Web Security Testing Guide als Fahrplan. Nehmen Sie nur die Checks ins Gate, die deterministisch laufen.

Compliance‑Korridor: Was Prüfer wirklich sehen wollen

Auditoren suchen keine Marketing‑Folien. Sie wollen sehen: kontrollierte Änderungen, festgelegte Verfahren, und unverrückbare Artefakte. Ein gutes Mapping hilft. Aus einem Feature wird ein Ticket, daraus wird ein Build, daraus ein Test‑Run, und am Ende liegt ein signierter Report. Alles verlinkt. Alles datiert.

Verweise auf externe Prüfstellen geben Halt. GLI Richtlinien und Testservices nennen klare Bereiche wie RNG, Sicherheit, Kommunikation. eCOGRA Prüf- und Zertifizierungsleistungen decken Remote‑Systeme, RTP‑Angaben und Prozesse ab. Unsere Evidenzen sollten diese Kapitel abbilden. So sprechen alle dieselbe Sprache.

CI/CD ohne Blindflug: Gates, Risiko‑Slicing, Flaky‑Disziplin

Ein schneller Release ist gut. Ein belegter Release ist besser. Ich setze Gates in drei Stufen:

• Vor Merge: Unit, Contract‑Tests, SAST, schnelle API‑Smokes.
• Vor Staging: UI‑Smokes, kritische Regressionsfälle, DAST‑Light.
• Vor Prod: RNG/RTP‑Kurzläufe, Payments‑Szenarien, Security‑Gate, Canary mit Rollback.

Die Pipeline selbst muss lesbar sein. Die Jenkins Pipeline Doku zeigt, wie man Stages klar trennt und Artefakte übergibt. Wer Cloud‑Repos nutzt, kann mit GitHub Actions für CI/CD saubere Reusable Workflows bauen. Wichtig ist weniger das Tool, mehr die Nachweise: Was lief? Mit welchen Daten? Wo liegt der Report?

Risiko‑Slicing spart Zeit. Hotfix? Nur kritische Pfade plus Security‑Gate. Major Release? Volle Suite. Flaky‑Tests gehören in Quarantäne. Messen Sie Flaky‑MTTR, vergeben Sie Ownership, und löschen Sie Zombies. Nichts frisst mehr Vertrauen als ein rotes Gate mit Schulterzucken.

Wenn der Jackpot‑Peak kommt: Performance und Resilienz

Die Last im iGaming kommt in Wellen. Turnierstart, Bonus‑Drop, Streamer‑Hype. Planen Sie Profile, nicht nur Peak‑Zahlen. Wichtige KPIs: p95/p99‑Latenzen, Fehlerbudget, Abbruchraten je Flow. Nur p50 ist Kosmetik.

Für Last nutze ich gern k6. Der k6 Leitfaden für Lasttests hilft beim Modell, bei Checks und bei Metriken. Resilienz gehört dazu: Was passiert bei PSP‑Timeout? Greifen Retries? Bleibt Idempotenz gewahrt? Chaos‑Light im Staging reicht oft, um fiese Ketten zu finden.

Sicherheit, aber pragmatisch

Security ist ein Prozess, kein Sprint. Auto‑Checks decken viel ab. SAST im Build findet viele Fehler früh. DAST prüft die echte Oberfläche. Secret‑Scanner halten Schlüssel aus dem Code. Dependency‑Audits schützen die Lieferkette. Rollen‑Tests prüfen, ob Backoffice‑User nur sehen, was sie müssen.

Als Basis dient die Liste der häufigsten Risiken. Die OWASP Top 10 sind bekannt, aber immer noch nützlich. Bauen Sie ein Gate: 0 kritische, 0 hohe Befunde. Alles andere braucht ein Ticket mit Frist.

Wo Menschen besser sind

Nicht alles lässt sich gut skripten. Neue Spiel‑Features leben von Gefühl, Ton, Tempo. Hier hilft exploratives Testen, am besten zusammen mit Game‑Design. Zwei Stunden zu zweit finden oft mehr als ein langer, starrer Plan. Und LiveOps? Da zählt Monitoring. Augen auf Metriken, Chat, Social‑Signale.

Transparenz nach außen: Fairness zeigen

Spieler wollen Klarheit. Studios auch. Gute Praxis: kurze Fairness‑Reports pro Spielversion. Darin stehen RNG‑Prüfungen, RTP‑Fenster, Datum, Prüfer, Links auf Zertifikate. Für Datenhaltung und Rechte lohnt ein Blick auf den GDPR Überblick. So ist klar, was man speichert, wie lange, und warum.

Warum das wichtig ist? Vertrauen zahlt ein. Studios, die Zertifikate und RTP‑Angaben sichtbar machen, schneiden in unabhängigen Vergleichen besser ab. Spieler suchen aktiv nach Anbietern, die mobil gut laufen. Viele prüfen Angebote über Seiten zu mobile Spielautomaten, sehen dort Lizenz, Fairness, und wie sauber mobile Slots performen. Wer klare Belege liefert, wird eher gewählt. Einfach, weil alles offenliegt.

Praktische Hinweise, die sofort tragen

• Packen Sie die RNG‑Läufe in eine eigene Pipeline. Lange Jobs sollen parallel laufen.
• Legen Sie Seeds, Ergebnisdateien und Hashes versioniert ab. Keine flüchtigen Artefakte.
• Nutzen Sie Contract‑Tests für PSP/KYC. Mocken Sie Fehler realistisch, nicht nur Happy Path.
• Halten Sie UI‑Tests klein. Tiefe Checks kommen über die API. So bleiben Tests schnell und stabil.
• Messen Sie Flaky‑Quote und MTTR getrennt. Nur so sieht man echten Fortschritt.
• Definieren Sie Metriken, bevor Sie Tools wählen. Sonst messen Sie am Ende nur das Tool.
• Schreiben Sie pro Release ein kurzes Readme: Was ändert sich? Wo liegt der Beweis?
• Verknüpfen Sie Tickets, Commits, Runs und Reports. Ein Klickpfad spart Stunden im Audit.

Mini‑FAQ: kurz, klar, praktisch

Wie belege ich RNG‑Fairness ohne Produktionsdaten?

Nutzen Sie feste Seeds und große Simulationsläufe in Staging. Speichern Sie Inputs (Seed, Code‑Hash, Config) und Outputs (CSV, p‑Werte, Signatur). So ist der Lauf reproduzierbar und auditierbar.

Welche Tests müssen bei einem Hotfix laufen?

Kritische Regressionsfälle, Security‑Gate, betroffener Contract‑Test, kurze RNG/RTP‑Checks, und ein minimales UI‑Smoke. Dazu Canary‑Rollout mit schneller Rückkehrmöglichkeit.

Woran erkenne ich zu viele UI‑Tests?

Lange Laufzeit, viele Flakes, und Tests, die nur Layout prüfen. Faustregel: Die meisten Regeln prüfen Sie per API. UI testet Kernwege, Fehleranzeigen und Rollen.

Welche Artefakte erwarten Auditoren?

Versionierte Testpläne, Pipeline‑Run‑Links, Reports mit Datum und Signatur, Protokolle zu Änderungen, Zertifikate (RNG/RTP), und eine Zuordnung zu Releases.

Wie setze ich Geofencing‑Tests rechtssicher um?

Testen Sie mit erlaubten Geo‑Datenbanken, Device‑Farms, und simulierten VPN/Cell‑Wechseln. Keine Umgehung echter Sperren in Live‑Systemen. Alle Tests laufen in Staging.

Ein Wort zu Metriken, die zählen

Nehmen Sie Metriken, die Entscheidungen treiben. Für QA: Defect‑Escape‑Rate (wie viel entkommt?), Test‑Efficacy (wie viel fangen wir früh?), Flaky‑MTTR (wie schnell stabilisieren wir?). Für Delivery: DORA‑Metriken, aber mit Qualität im Blick. Lieber ein Release später, dafür mit Belegen, die standhalten.

Kurzer Blick in die Zukunft

Mehr Tests laufen bald direkt im Build‑System, mit deterministischen Datenräumen. Testdaten werden Teil des Codes, mit Reviews und Checks. Und Fairness‑Reports werden normal wie Changelogs. Das ist gut so.

Fazit zum Mitnehmen

Testautomatisierung in Casino‑Software ist kein Selbstzweck. Sie liefert Beweise. Für Fairness, für Stabilität, für Sicherheit. Mit UI + API + Batch + Contract + klaren Gates bauen Sie ein System, das Releases nicht nur möglich, sondern verantwortbar macht. Starten Sie klein, aber mit Artefakten. Alles andere wächst dann gesund nach.

Micro‑CTA: Prüfen Sie jetzt Ihre Audit‑Readiness mit der Tabelle oben. Verlinken Sie die Evidenzen dort, wo Spieler sie finden – in Ihren Spiel‑Seiten und Release‑Notes.

Quellen und nützliche Links (einmalig verlinkt, nach Abschnitten sortiert)

• Regulatorik: Remote Technical Standards der UK Gambling Commission
• Qualitätsmodell: ISO/IEC 25010 Qualitätsmodell
• RNG/Statistik: NIST SP 800‑22 Tests für Zufallszahlen
• UI/API‑Automation: Playwright Dokumentation
• Security‑Prüfungen: OWASP Web Security Testing Guide
• Zertifizierungen: GLI Richtlinien und Testservices, eCOGRA Prüf- und Zertifizierungsleistungen
• CI/CD: Jenkins Pipeline Doku, GitHub Actions für CI/CD
• Performance: k6 Leitfaden für Lasttests
• AppSec: OWASP Top 10
• Datenschutz: GDPR Ãœberblick

Ãœber die Autorin/den Autor

QA‑Lead im iGaming mit 10+ Jahren Erfahrung in RNG/RTP‑Prüfungen, CI/CD‑Gates und Compliance‑Audits (GLI/eCOGRA). Arbeitet eng mit Produkt, Sicherheit und Compliance zusammen. Zuletzt aktualisiert: heute. Änderungslog: Feinschliff an Tabelle; Links geprüft.