Im Sommer haben wir über die Arbeit unserer QA-Teams gesprochen, welche Schwerpunkte jedes Team hat und wie wichtig diese Teams für den gesamten Entwicklungsprozess des Spiels sind – sie machen viel mehr als nur Bugs zu suchen oder Anno 1800 zu testen. Falls ihr es noch nicht gelesen habt, empfehlen wir euch dringend, dies zu tun, bevor ihr weiterlest, um zunächst etwas über die Aufgaben und Verantwortungsbereiche unserer drei Teams zu erfahren: unser internes QA-Team, das Live-QA-Team und die Qualitätskontrollteams.

Und wie bereits erwähnt, wollen wir euch nun einen Einblick geben, welche Schritte vom Finden eines Problems bis zur Veröffentlichung eines Fixes unternommen werden

Damit ihr euch schnell einen ersten Überblick verschaffen könnt, werft einen Blick auf die folgende Grafik. Im Blog selbst werden wir dann ins Detail gehen.

Finden oder Melden eines Problems

Normalerweise gibt es zwei Möglichkeiten, wie ein Problem auf unserem Radar auftaucht: Entweder wird es von euch über einen unserer Kanäle gemeldet (oder von einem der Anno Companions an uns weitergeleitet), oder wir bemerken es beim internen Testen – oder Spielen 😉

In beiden Fällen wird das Problem in JIRA eingetragen, einem Tool, das für verschiedene Zwecke verwendet werden kann, in diesem Fall verwenden wir es, um Fehler zu sammeln und zu kategorisieren. Während dieses Prozesses wird jedes Problem anhand mehrerer Faktoren kategorisiert und bei Bedarf mit Tags versehen, die wichtigsten Beiden: Schweregrad(Severity) (Auswirkung des Fehlers, wenn er auftritt) und Wahrscheinlichkeit(Probability) (wie wahrscheinlich ist es, dass Spieler auf dieses Problem stoßen)

Aus diesen beiden Faktoren ergibt sich dann die Priorität (z.B. ein Problem mit hoher Wahrscheinlichkeit, aber geringem Schweregrad, hat eine niedrige oder mittlere Priorität).

Reproduktion

Der nächste Schritt ist sehr wichtig: Wir versuchen, das Problem zu reproduzieren, d. h. wir versuchen, es bei uns absichtlich auftreten zu lassen. Das hilft uns, mögliche Ursachen für das Problem ausfindig zu machen, was es uns wiederum viel leichter macht, das Problem später anzugehen und zu beheben.

Dieser Schritt kann manchmal recht arbeitsintensiv sein. Um beispielsweise Probleme der Live-Version zu reproduzieren, benötigt das QC-Team manchmal eine ganz bestimmte Hardware-Kombination für Tests, die unter Umständen nur sehr schwer zu beschaffen ist.   Manchmal bedeutet dies auch, dass wir direkt mit Hardwareherstellern wie AMD oder Nvidia zusammenarbeiten müssen, um bestimmte Hardwarekombinationen zu erhalten oder zu testen, um bestimmte Probleme zu reproduzieren und zu untersuchen.

Daher ist es für uns äußerst hilfreich, wenn ihr uns bei der Meldung von Problemen so viele Details wie möglich gebt: Könnt ihr das Problem selbst reproduzieren? Was habt ihr getan, bevor das Problem auftrat? Welche Hardware verwendet ihr? Etc.

Bei Anno 1800 kommt es aufgrund der vielfältigen Einstellungsmöglichkeiten und des individuellen Spielstils jedes Spielers häufig vor, dass das Live QA-Team nach Erhalt der ersten Meldung um Speicherstände, Screenshots, Videos oder Systeminformationen bitten muss. An dieser Stelle kommen der Kundensupport und das Community Management Team ins Spiel: Sie setzen sich mit dem Spieler in Verbindung und stellen nach Möglichkeit weitere Informationen zur Verfügung.

Diese Reproduktionsschritte werden daher auch in jedem JIRA-Ticket aufgeführt, damit jeder, der an diesem Problem arbeitet, es schnell selbst überprüfen kann. Außerdem wird eine Reproduktionsrate hinzugefügt: Kann das Problem jedes Mal reproduziert werden, wenn bestimmte Schritte befolgt werden, oder tritt es nur gelegentlich auf? Oder können wir ein Problem, das uns gemeldet wurde, eventuell gar nicht reproduzieren?

Behebung des Problems

Die Behebung des Problems bedeutet, dass die Ursache des Problems mit Hilfe der bereitgestellten Informationen weiter untersucht wird.

Dies geschieht auf der Grundlage der in Schritt 1 vorgenommenen Prioritätensetzung. Weitere Faktoren sind die verfügbaren Ressourcen innerhalb des Teams. Das kann bedeuten, dass selbst wenn ein Problem eine niedrige Priorität hat, der Bugfix trotzdem in das Game Update wandert, wenn wir in der zuständigen Abteilung freie Ressourcen haben. Bedenkt, dass das Team gleichzeitig auch am nächsten größeren Update oder DLC arbeitet.

Wir möchten an dieser Stelle auch betonen, dass es natürlich stark von der Art des Problems abhängt, welches Team für die Behebung zuständig ist. Ein falscher Questtext? Eine fehlende Textur? Ein Item-Effekt, der nicht funktioniert? Falsch ausgerichtete Icons? Jedes Problem kann einen bestimmten Spezialisten erfordern.

Obwohl es in einigen Fällen möglich sein kann, dass einer unserer Programmierer die Ursache und den Ort eines Problems ohne Reproduktionsschritte herausfindet, ist dies nicht die Regel und verlängert die Zeit, die für das entwickeln eines FIxes benötigt wird, erheblich.

Abgesehen davon kann jede Art von Fehlerbehebung geraume Zeit in Anspruch nehmen, da die Suche nach der genauen Ursache in der Regel keine Sache von Minuten ist: Wir müssen herausfinden, was genau zu dem Verhalten führt, das wir beobachtet und reproduziert haben. Außerdem gibt es mögliche Risiken, vor allem weil Videospiele wie Anno 1800 sehr komplex sind: Die Behebung eines Fehlers kann dazu führen, dass ein anderes System nicht mehr wie vorgesehen funktioniert, neue Fehler können auftreten, usw. Einige Systeme des Spiels sind weitaus schwieriger zu bearbeiten als andere.

Test des Bugfixes

Deshalb muss jeder Fix richtig getestet werden. Nicht nur isoliert für sich selbst (ist der Fehler behoben?), sondern auch in Kombination mit dem Rest des Game Updates – d.h. der neuen Version des Spiels. Damit soll sichergestellt werden, dass eine Fehlerbehebung nicht, wie oben erwähnt, etwas anderes kaputt macht.

Detaillierte Reproduktionsschritte sind daher auch für die Tests wichtig, da wir wissen müssen, wie man ursprünglich auf den Fehler stoßen konnte: Tritt das Problem jetzt NICHT mehr auf, nachdem man die skizzierten Schritte befolgt hat?

Wie ihr vielleicht schon erraten habt, ist das Testen, ähnlich wie bei den vorherigen Schritten, nicht an einem Tag erledigt. Bevor wir ein Game Update veröffentlichen, legen wir in der Regel eine „Validierungsperiode“ ein. Dieser Zeitraum ist in der Regel etwa 2 Wochen lang und besteht aus zwei Phasen:

1. Die erste findet intern hier in Mainz statt und ist ein „Feature Freeze“, den wir die „Golden Ticket Phase“ nennen – denn nur von QA genehmigte, „goldene“ JIRA Tickets dürfen noch bearbeitet und in das Update aufgenommen werden. Alles andere muss auf ein zukünftiges Update warten.
2. In der zweiten Woche führen unsere Kollegen in den QC-Teams die Validierung des Updates durch. Wir arbeiten zu diesem Zeitpunkt nicht mehr an dem Update.

Natürlich kann es vorkommen, dass eine bestimmter Fix oder gar das Game Update selbst nicht funktioniert oder Probleme aufweist. In diesem Fall müssen wir zu den vorherigen Schritten zurückkehren (einschließlich einer weiteren Validierungsrunde), was im schlimmsten Fall bedeuten kann, dass wir die Veröffentlichung des Game Updates verschieben müssen.

Release des Game Updates

Wenn die neue Version getestet und validiert wurde, sind wir fast bereit für die Veröffentlichung. Während dieses Prozesses stehen wir auch in Kontakt mit Kollegen in anderen Teams, damit alle wissen, dass wir das Update an diesem Tag veröffentlichen wollen.

In der Regel bündeln wir in einem solchen Game Update stets mehrere Bugfixes: Das kann bedeuten, dass einige Probleme zwar bereits behoben sind aber erst darauf warten müssen, in die Live-Version des Spiels übertragen zu werden. Aufgrund des hohen Arbeitsaufwands müssen wir ein Gleichgewicht zwischen der rechtzeitigen Behebung eines Problems und der Vermeidung einer Überlastung unserer Teams durch ständige Game Update Veröffentlichungen finden.

Der „Hotfix“ ist eine Ausnahme, und wir haben in unserem vorherigen DevBlog darüber gesprochen.

Unsere großen Game Updates, die zusammen mit einem DLC veröffentlicht werden, gehen in der Regel um 18:00 Uhr live, während die kleineren Updates in der Regel um 14:00 Uhr veröffentlicht werden. Und falls ihr es noch nicht bemerkt habt: Unser bevorzugter Veröffentlichungstag ist der Dienstag.  😉

Da wir regelmäßig Missverständnisse über unsere internen Prozesse und die Zeit, die für die Behebung von Fehlern und anderen technischen Problemen benötigt wird, erleben, war es für uns eine Priorität, dieses Thema genauer zu beleuchten.

Wie wir in diesem Blog hoffentlich deutlich gemacht haben, ist der Prozess, der hinter dem Melden von Fehlern und der Fehlerbehebung steht, nicht einfach: Er erfordert Zeit und vor allem viel Geduld und Ressourcen.

Wenn ihr Fragen dazu habt oder mehr über andere spezifische Prozesse wissen möchten, zögert nicht, uns das in den Kommentaren unten mitzuteilen!