Game Testing

Game Testing für ein MMORPG bedeutet, ein seit Jahrzehnten gewachsenes Spiel mit jeder Woche neuen Patches auf Qualität zu prüfen. Explorative Tests stehen dabei neben Checklisten, God-Spells ersetzen mühsames Leveln, und zweimal jährlich testen bis zu 70.000 echte Spieler neue Features in einer separaten Testumgebung, bevor das offizielle Update erscheint.

Das Wichtigste in Kürze

• Explorative Tests haben beim Testen des MMORPGs Tibia einen höheren Stellenwert als das reine Prüfen gegen Anforderungsdokumente, weil viele Risiken erst zwischen den Zeilen der Designdokumente stecken.
• Ein Bug, der Spieler ungerechtfertigt sterben lässt, ist kein kosmetisches Problem: In Tibia verliert man dabei Fortschritt, der eine Woche harter Spielzeit kostet, was direkt zur Abwanderung führt.
• Beim externen Test mit bis zu 70.000 eingeladenen Spielern deckt die kritische Masse an Nutzern Fehler und Balancing-Probleme auf, die das interne Team nicht vorhersehen konnte.
• Ohne spielinterne Testwerkzeuge, sogenannte God-Spells, wäre es praktisch unmöglich, Spielzustände gezielt herzustellen und Quests mitten in ihrer Abfolge zu testen, ohne stundenlang vorher spielen zu müssen.
• Die Release-Entscheidung bei Tibia basiert nicht allein auf grünen Haken in Checklisten, sondern auch auf dem persönlichen Bauchgefühl der Tester, die das jeweilige Feature durchgetestet haben.

Warum Spiele getestet werden müssen

Ein Online-Spiel ohne Test setzt seine Spieler einem hohen Risiko aus, und das kostet am Ende Vertrauen und Geld. Bei einem Massive-Multiplayer-Spiel wie Tibia, das seit 1997 läuft, wiegt jeder Fehler schwer, weil die Spieler echte Zeit in ihre Charaktere investieren.

Stirbt ein Charakter wegen eines Bugs, ist das im Spiel teuer erkauft. Oliver Heldt beschreibt es so: Da spielst du eine Woche auf etwas hin, und dann stirbst du, weil ein Fehler im Code steckt. Wer das erlebt, verliert die Lust am Spiel.

Die Begründung ist deshalb wirtschaftlich und emotional zugleich. Ein Studio will seine Spieler halten und ein Produkt mit verlässlicher Qualität liefern. Das Argument “ein Spiel ist nicht lebensnotwendig, also muss man es nicht testen” greift zu kurz, sobald eine Community über Jahre an einem Produkt hängt.

Was ein 25 Jahre altes Spiel testbar macht und was nicht

Die größte Herausforderung bei einem alten Spiel ist die schiere Menge an gewachsenem Content, der bei jeder Änderung mitbedacht werden muss. Tibia bekommt wöchentlich einen Patch, dazu kommen Zwischenreleases und große Updates wie ein Sommer-Update.

Ein solches Update bringt neue Abenteuer, neue Funktionen und neue Logiken, die parallel zum Bestehenden funktionieren müssen. An einem großen Update arbeitet das Testteam rund sieben Wochen und teilt die Arbeit so auf, dass die nötige Qualität in der Zeit erreichbar bleibt.

Die zentrale Frage ist nicht “haben wir alles getestet”, sondern “wie tief testen wir das Alte, wenn etwas Neues dazukommt”. Du kannst ein über 25 Jahre gewachsenes Spiel nicht bei jedem Release komplett neu durchtesten. Also entscheidest du bewusst, wo das Risiko liegt und wie weit du dort hineingehst.

Explorativ testen schlägt stures Abhaken

Beim Spieletest hat exploratives Testen einen hohen Stellenwert, weil sich Risiken selten vollständig aus einer Anforderung ablesen lassen. Es gibt Grunddesign- und Umsetzungsdokumente, gegen die geprüft wird, aber das ist nur die eine Seite.

Auf eine einzelne Anforderung kommen viele explorative Tests. Die eigentliche Arbeit besteht darin, zwischen den Zeilen der Dokumente zu lesen und herauszufinden, wo sich ein Risiko versteckt. Reines Prüfen, ob etwas rot oder grün ist, reicht für ein lebendiges Online-Spiel nicht.

Produktwissen hilft dabei, ersetzt aber Intuition und frische Sichtweisen nicht. Neue Kollegen bringen einen anderen Blick mit, und genau dieser Input deckt Dinge auf, die ein eingespieltes Team übersieht.

Wie Checklisten als Inspiration statt als Pflichtprogramm wirken

Checklisten dienen beim Spieletest vor allem als Inspiration, nicht als abzuarbeitendes Pflichtprogramm. Für klar umrissene Fälle, etwa ein neues Outfit oder einen neuen Mount, greift das Team auf erfahrungsbasierte Checklisten zurück, die typische Fehlerquellen abdecken.

Auch Smoke-Test-Listen existieren, ihr Zweck liegt aber woanders. Sie sollen anregen, wie tief ein neues Feature getestet werden soll. Es geht nicht darum, am Ende möglichst viele grüne Haken zu sammeln.

Ist die Checkliste für ein neues Outfit sauber durchgelaufen, ist der Test noch nicht zu Ende. Sie liefert eine gute Basis, mehr nicht. Den Rest entscheidet die Frage nach der gewünschten Testtiefe.

Ein guter Bug-Report braucht eine Repro, die deine Oma versteht

Der wichtigste Teil eines Fehlerberichts ist eine reproduzierbare Schritt-für-Schritt-Anleitung, die ohne Rückfragen funktioniert. Oliver Heldt formuliert den eigenen Anspruch deutlich.

Es wäre cool, wenn du es deiner Oma geben könntest und die wüsste ungefähr, wie es reproduzierbar ist. : Oliver Heldt

Eine solche Repro kann umfangreich sein, denn an einem Fehler sind manchmal mehrere Spieler beteiligt, die bestimmte Aktionen in einem bestimmten Timing ausführen. Dreimal einen Button drücken reicht als Beschreibung dann nicht.

Zum Report gehören Step-by-Step-Listen und Screenshots, seltener Videos. Videos kommen eher von den Spielern. Der Maßstab bleibt gleich: Der Entwickler soll so wenig wie möglich nachfragen müssen, und ein anderer Tester soll den Fehler ebenfalls nachstellen können. Ein “internal error auf der Webseite” als einzige Information hilft niemandem.

God-Spells: warum Tester im Spiel cheaten dürfen

Tester arbeiten mit sogenannten God-Spells, also eingebauten Eingriffsmöglichkeiten, die den Test überhaupt erst praktikabel machen. Aus Spielersicht wäre das Cheaten, im Test hat jeder dieser Spells einen klaren Zweck.

Die Bandbreite reicht vom Teleportieren statt langem Laufen über das Setzen eines bestimmten Levels bis zum Abfragen und Setzen von Quest-Zuständen. So bringst du einen Charakter schnell in die Situation, die du gerade prüfen willst, und sparst viel Zeit.

Ohne diese Werkzeuge wären manche Tests gar nicht möglich. In einem Gebiet voller Monster würde ein Tester schlicht sterben, weil er nicht das Niveau erfahrener Spieler hat. Manche von ihnen spielen Tibia seit zehn oder zwanzig Jahren. Es geht im Test nicht darum, besser zu sein als sie, sondern darum, eine Logik kontrolliert untersuchen zu können.

Dazu kommen Testcharaktere und Logfiles. Ein Charakter mit extrem vielen Items eignet sich gut für einen ersten Durchlauf, weil dort mehr schiefgehen kann. Für gezielte Tests stehen vorbereitete Charaktere bereit. Alles, was an Information hilft, ein Verhalten als richtig oder falsch zu bewerten, fällt in dieselbe Manipulations- und Informationsschiene.

Wie 50.000 Spieler zum Teil des Tests werden

Echte Spieler kommen nach dem internen Test ins Spiel, in einem externen Test über drei bis vier Wochen. Zweimal im Jahr werden dafür zwischen 50.000 und 70.000 Spieler eingeladen, bei rund 500.000 aktiven Spielern insgesamt.

Für diesen externen Test gibt es einen eigenen Test-Server und eine eigene Webseite. Die Spieler bekommen keine Checkliste, sie sollen das Spiel so spielen wie sonst. Aus dem Spiel heraus erstellen sie per Rechtsklick einen Bug-Report, der direkt die Position und die Beschreibung des Fehlers liefert.

Zurück kommen vor allem Kleinigkeiten: ein Rechtschreibfehler, eine Stelle an einer Hauswand, an der etwas nicht stimmt, oder ein Punkt, an dem man hängen bleibt. Genau die Fehler also, die intern als Minor-Bugs liegen gelassen wurden. Die kritische Masse an Spielern deckt aber auch Dinge auf, die im internen Test niemand auf dem Schirm hatte.

Der externe Test dient außerdem dem Balancing. Ist ein Boss zu stark, sind es zu viele Monster, wird eine der vier Vocations durch eine neue Logik überlegen? Über Kennzahlen lässt sich vor dem Release nachjustieren, was sich intern schwerer bewerten lässt.

Spieler probieren alles aus, also musst du an alles denken

Spieler suchen aktiv nach Wegen, das System zu überlisten, und genau diese Versuche muss der Test vorwegnehmen. Was gemacht werden kann, wird gemacht.

Ein Beispiel: Vor einem NPC, der dem Spieler ein Item abnehmen will, versuchen Spieler, dieses Item vorher auf den Boden zu werfen, damit der NPC es nicht einziehen kann. Solche Tricks werden ausprobiert, um an Geld oder Vorteile zu kommen, die ihnen nicht zustehen.

Diese Anomalien zur echten Welt sind der Stoff, an dem Tests scheitern oder bestehen. Oft ist die Reaktion ehrlich: Daran hatte niemand gedacht. Das gehört zur Arbeit dazu.

Wann ein Release fertig genug ist

“Fertig” ist beim Spieletest ein Zustand aus Daten und Vertrauen, nicht aus vollständiger Abdeckung. Es gibt ein Due Date, und in der Regel ist die Qualität bis dahin auf dem gewünschten Stand, jedes Feature so tief getestet wie geplant.

Die Entscheidung trifft das Team gemeinsam, sie stützt sich aber stark auf Erfahrungswissen. Der Teamleiter fragt die Tester, die ein Feature bearbeitet haben, ausdrücklich nach ihrem Gefühl. Dieses Gefühl zählt neben den grünen Haken und den geschlossenen Issues.

Reicht das Vertrauen nicht, gibt es einen Nachtest. Dann muss das Team mit Entwicklern und Produktmanagern ehrlich sein und sagen, dass es ein paar Tage mehr braucht, weil etwas bei der Schätzung übersehen wurde. Weil intern fürs eigene Produkt getestet wird, ist dieser Schritt möglich, ohne gegen einen externen Kunden zu argumentieren.

Auch nach 25 Jahren bleibt technisch genug zu testen

Ein altes Spiel steht nicht still, neue Technik kommt regelmäßig dazu und bringt eigene Testaufgaben mit. Tibia bleibt grafisch in 2D, ein Sprung auf neue Grafik ist nicht geplant. Trotzdem wächst der technische Umfang.

Beispiele sind eine eigene App mit Spielinformationen oder die komplette Vertonung des Spiels, das davor tonlos war. Diese Vertonung war eine große Testaufgabe, weil Sound nicht einfach an und aus geht.

Der Klang folgt einer Logik und muss zum Aufenthaltsort passen, an einer Küste anders als an einem Brunnen. Spieler können den Sound granular steuern, etwa nur die Waffen oder nur die Zaubersprüche anderer abschalten. Im Test arbeitest du dann viel mit Logfiles und Manipulation, um zu bewerten, ob der Sound an dieser Stelle der richtige ist, ohne stundenlang auf das nächste Musikstück zu warten.

Bekannte Bug-Klassiker und was sie lehren

Selbst sorgfältig getestete Spiele schaffen es nicht, jeden Fehler abzufangen, weil sich nicht alles testen lässt. Diese Grundregel des Testens zeigt sich an konkreten Fällen aus der Produktion.

• Ein Furzkissen ließ sich stapeln. Stapelte ein Spieler zu viele übereinander, lief ein Datentyp über, und Client oder Server stürzten ab.
• Ein Cube erlaubte einem Spieler, einem anderen auf den Kopf zu schlagen und anschließend zu verschwinden, statt wie üblich bestraft zu werden.
• Eine Event-Insel, an der wochenlang gearbeitet wurde, war nach einer berechtigten Änderung am Zugang plötzlich nicht mehr erreichbar. Aufgefallen ist das erst in der externen Testphase.

Diese Fälle eint ein Muster: Eine sinnvolle Änderung an einer Stelle bricht eine andere, an die im Moment der Änderung niemand dachte. Spät im Release angefasste Stellen lassen sich nicht mehr vollständig neu testen, also kann etwas durchrutschen. Der wöchentliche Patch-Rhythmus federt das ab, weil sich solche Fehler zeitnah beheben lassen.