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 Game Testing bei Online-Spielen nötig ist
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.
Häufig gestellte Fragen
Welche Folgen hat ein Bug, der einen Spielercharakter sterben lässt?
Der Spieler verliert Fortschritt, für den er real eine Woche gespielt hat. Das ist kein kosmetisches Problem, sondern ein Grund, das Spiel zu verlassen. Bei einem MMORPG wie Tibia, das seit 1997 läuft, hängen Spieler jahrelang an ihren Charakteren. Deshalb ist die Begründung fürs Testen wirtschaftlich und emotional zugleich.
Genügt es, ein Spiel gegen seine Designdokumente zu prüfen?
Nein. Grunddesign- und Umsetzungsdokumente decken nur eine Seite ab, auf eine einzelne Anforderung kommen viele explorative Tests. Die eigentliche Arbeit besteht darin, zwischen den Zeilen zu lesen und Risiken zu finden, die niemand aufgeschrieben hat. Produktwissen hilft dabei, ersetzt Intuition aber nicht: Neue Kollegen sehen Dinge, die ein eingespieltes Team übergeht.
Sind abgehakte Checklisten ein Zeichen für einen ausreichenden Test?
Nein. Checklisten wirken als Inspiration, nicht als Pflichtprogramm. Für klar umrissene Fälle wie ein neues Outfit oder ein neues Mount gibt es erfahrungsbasierte Listen mit typischen Fehlerquellen, dazu Smoke-Test-Listen. Läuft eine solche Liste sauber durch, ist der Test noch nicht zu Ende. Sie liefert eine Basis, die Testtiefe wird gesondert entschieden.
Was gehört in einen Fehlerbericht, damit Entwickler möglichst wenig nachfragen müssen?
Eine reproduzierbare Schritt-für-Schritt-Anleitung, dazu Screenshots, seltener Videos. Der Maßstab: Auch eine völlig unbeteiligte Person soll ungefähr verstehen, wie sich der Fehler nachstellen lässt. Manche Repros werden lang, weil mehrere Spieler bestimmte Aktionen in einem bestimmten Timing ausführen müssen. Eine Meldung wie “interner Fehler auf der Webseite” hilft niemandem weiter.
Welche Werkzeuge brauchen Tester innerhalb eines laufenden Spiels?
Eingebaute Eingriffsmöglichkeiten, bei Tibia God-Spells genannt: teleportieren statt laufen, ein bestimmtes Level setzen, Quest-Zustände abfragen und ändern. Ohne sie ließen sich Spielzustände nicht gezielt herstellen, und in einem Gebiet voller Monster würde ein Tester schlicht sterben. Dazu kommen vorbereitete Testcharaktere, etwa einer mit sehr vielen Items, sowie Logfiles.
Was bringt ein offener Test mit echten Spielern zusätzlich zum internen Test?
Die kritische Masse an Nutzern. Bei Tibia werden zweimal im Jahr 50.000 bis 70.000 von rund 500.000 aktiven Spielern für drei bis vier Wochen auf einen eigenen Testserver eingeladen. Sie spielen ohne Checkliste und melden Fehler per Rechtsklick aus dem Spiel heraus. Der Test liefert außerdem Kennzahlen fürs Balancing, etwa zu zu starken Bossen.
Kann eine Freigabeentscheidung auch auf dem Bauchgefühl der Tester beruhen?
Ja. Der Teamleiter fragt die Tester, die ein Feature durchgetestet haben, ausdrücklich nach ihrem Gefühl, und dieses Gefühl zählt neben grünen Haken und geschlossenen Issues. Reicht das Vertrauen nicht, folgt ein Nachtest. Das Team sagt Entwicklern und Produktmanagern dann offen, dass es ein paar Tage mehr braucht.
Warum rutschen trotz sorgfältigem Test Fehler in ein Release?
Weil sich nicht alles testen lässt und spät geänderte Stellen nicht mehr vollständig neu geprüft werden können. Eine sinnvolle Änderung bricht dann etwas anderes: Eine Änderung am Zugang machte eine Event-Insel unerreichbar, aufgefallen ist das erst im externen Test. Der wöchentliche Patch-Rhythmus federt solche Fälle ab, weil Korrekturen zeitnah ausgeliefert werden.
