Hey Anno Community!

heute wollen wir ein wenig Licht in die Arbeit des QA-Teams bringen und euch einen Einblick in unsere Prozesse geben: Welche Rolle erfüllt jedes der Teams? Unterscheidet sich die Arbeit vor und nach der Veröffentlichung des Spiels? Was ist ein Hotfix und in welchen Situationen veröffentlichen wir sie?

Dazu haben wir uns mit Dorina, unserer QA-Managerin hier in Mainz, sowie – für zusätzliche Einblicke – mit Nadiia, Senior Development Tester hier in Mainz (früher: QC Project Lead) und Artem, Live QA Specialist, zusammengesetzt.

In zwei Sätzen: Was macht das QA-Team?

Einer reicht ja schon ? Wir stellen die Qualität des Produktes sowie des gesamten Produktionsprozesses sicher.

Wir wissen also, dass ihr nicht den ganzen Tag nur nach möglichen Problemen sucht. Welche weiteren Aufgaben erfüllt dein Team?

Da gibt es eigentlich ziemlich viele.

Generell fungiert die QA als Info-Hub, wo Informationen aus allen Teams zusammenlaufen. Wir behalten den Überblick über den Status von Problemen und in Entwicklung-befindlichen Features, behalten die Projektplanung im Auge und sammeln Informationen über Features und Mechaniken.

Wir betreiben auch Risikomanagement, d.h. wir eskalieren Probleme in Bezug auf das Projekt und das Produkt an das Produktionsteam oder andere Abteilungen. Beispiele dafür könnten sein, dass wir die Planung des Ressourcenmanagements betonen (d.h. zu viele Aufgaben für zu wenige Leute in zu wenig Zeit) oder Workflow-Probleme innerhalb des Teams aufdecken: Vielleicht sind Prozesse unnötig kompliziert oder inkonsistent zwischen den Teams und so weiter Natürlich gehört zum Risikomanagement auch die Priorisierung von Testbereichen und das Beheben von Fehlern.

Ein weiteres wäre das Geben von Feedback zu Features und Systemen während der Entwicklung und in der Konzeptphase. Das QA-Team besteht aus Leuten mit tiefem Wissen über das Spiel und seine Systeme, aber auch aus Leuten mit sehr unterschiedlichen Spielstilen und allgemeinen Vorlieben, wenn es um Videospiele als Ganzes geht. Das bedeutet, dass wir aus verschiedenen Perspektiven Feedback zu solchen Fragen geben können wie: Glauben wir, dass die vorgeschlagenen neuen Features Spaß machen werden? Gibt es zwei Systeme, die kollidieren und nicht zueinander passen? Ist ein Feature überflüssig, da es bereits etwas sehr Ähnliches im Spiel gibt?

Wir sind auch die Admins für verschiedene interne Tools. Ein wichtiges ist JIRA (ein Tool, das für verschiedene Zwecke genutzt werden kann, in diesem Fall nutzen wir es, um Bugs zu melden und zu verfolgen) neben einigen anderen, die zum Testen genutzt werden.

Und schließlich organisieren wir auch die Validierungen für jeden Release, sei es DLC oder Game Update. Dazu später mehr.

Für noch mehr Details über die Arbeit unserer QA, schaut euch doch diesen älteren Blog an.

Wie verändert sich eure Arbeit von der Zeit vor Release zur Zeit danach?

Ein großer Unterschied ist sicherlich, dass jetzt viel mehr `Spieler-Feedback eingeht. Das bedeutet natürlich mehr Arbeit an diesen Live-Problemen und erfordert von uns viel mehr Priorisierungsarbeit: Wie wichtig und wie schwerwiegend ist das Feedback oder der Fehlerbericht?

Außerdem haben wir natürlich deutlich mehr Releases, was bedeutet, dass alle paar Monate neue Versionen fertiggestellt und validiert werden müssen.

Auf der anderen Seite: Es werden jetzt in der Post-Launch-Phase viel weniger Features gestrichen. Wenn also etwas als Teil eines DLCs geplant ist, können wir als QA in der Regel so planen, dass dieses Feature auch veröffentlicht wird und ein Test nicht dadurch ungültig wird, dass eine bestimmte Mechanik plötzlich nicht mehr im Spiel ist.

Ihr seid direkt hier in Mainz im Studio verortet. Arbeitet ihr mit anderen QA-Teams zusammen? Wie ist die Arbeit zwischen euch aufgeteilt?

Wir arbeiten mit zwei anderen Teams zusammen, die nicht direkt hier im Studio sitzen: Quality Control (QC) und Live QA, die jeweils einen anderen Schwerpunkt haben.

Lasst uns zuerst einen Blick auf die Arbeit von Live QA werfen:

Es handelt sich dabei um ein Team von QA-Spezialisten, die den Post-Launch-Support (d.h. sie betreuen das Spiel nach seiner Veröffentlichung) für Ubisofts Spiele und Dienste übernehmen. Alle ihre Tests finden in der Live-Umgebung (also der gleichen Spielversion, die ihr auch verwendet) statt, was bedeutet, dass sie keine Debug-Optionen oder Cheats haben, um Inhalte zu überspringen oder mit unbegrenzten Ressourcen zu spielen.

„Wir helfen dem Produktionsteam, ein vollständigeres Bild zu erhalten und sicher eine fundierte Entscheidung zu den oben genannten Probleme zu treffen.“

Indem sie das exakte Endbenutzer-Setup haben – oder versuchen, es zu haben – sind sie in der Lage, Live-Informationen über das Produkt zu liefern, sowohl für Produktions- als auch für Business-Themen. Sie verwenden auch JIRA (allerdings nicht dasselbe, das wir im Studio verwenden) für ihre tägliche Arbeit: Für jedes Problem, das hereinkommt, ist es ihr Job und ihre Verantwortung, es zu reproduzieren und das JIRA-Ticket danach auf dem neuesten Stand zu halten, wenn neue Informationen reinkommen.

LiveQA ist ein sehr transversales Team, was bedeutet, dass sie mit mehreren Teams zusammenarbeiten, darunter natürlich das Produktionsteam bei den tagtäglichen Aufgaben, während andere Themen es nötig machen, mit Leuten aus etlichen anderen Job-Bereichen in Kontakt zu treten.

Dazu gehören der Kundensupport oder das Community Management, um den Spieler zu erreichen und unter Umständen nach weiteren Informationen zu fragen, sowie das Release Management (beim Überprüfen, dass all alle versprochenen Inhalte korrekt funktionieren, bspw. „Können Spieler ihren Vorbestellerbonus problemlos aktivieren?“ ), die Qualitätskontrolle, das Ubisoft Connect Team und alle möglichen anderen Ubisoft Dienste wie der Store oder die Ubisoft Plus Teams.

Das dritte Team ist QC – das Quality Control (Qualitätskontroll-) Team – und hat getreu seinem Namen eine Fülle von verschiedenen Aufgaben.

Es stellt sicher, dass das Spiel alle notwendigen Anforderungen erfüllt, die für den Titel gelten: Qualitätsstandards für den aktuellen Meilenstein (z.B. kommendes Game Update/DLC), technische Ubisoft-Anforderungen und First-Party-Anforderungen (für Spiele, die in anderen Stores als dem Ubisoft Store erscheinen, Spiele, die auf Konsolen veröffentlicht werden, etc.) sowie Partnerschaftsanforderungen (dies kann sich auf Partnerschaften mit z.B. Amazon beziehen).

Daher besteht QC aus einer Vielzahl von Teams: dem funktionalen Spieletester-Team, das die Features und Mechaniken des Spiels testet, und einer Liste von „Technische Standards Teams“, z.B. PC-Anforderungen, Ubisoft Online-Anforderungen, UX-Anforderungen, Online-Performance und Networking (d.h. Multiplayer-bezogene Dinge), Tracking, Lokalisierung, etc.

All diese Teams arbeiten während der gesamten Hauptproduktions- und Post-Launch-Zeit in enger Zusammenarbeit miteinander und mit dem Produktionsteam in Mainz. Jedes Spiel-Update, das live geht, durchläuft zunächst die Validierung durch all diese Teams, die dann einen detaillierten Bericht über die Ergebnisse erstellen.

Insgesamt muss man betonen, dass all dies eine große Teamleistung ist, bei der alle drei Teams zusammenarbeiten, um sicherzustellen, dass wir Spiel-Updates und DLC rechtzeitig veröffentlichen können, früh genug von potenziellen Problemen erfahren, fundierte Entscheidungen treffen und Probleme, wenn sie auftauchen, je nach ihrer Priorität angehen können.

Ich habe einen Fehler in den Foren gemeldet, wie lange dauert es, bis er behoben ist?

Im Allgemeinen hängt die Zeit, die es braucht, um einen Fehler zu beheben, von mehreren verschiedenen Faktoren ab, vom Schweregrad über die Komplexität bis hin zu unserer aktuellen Projektplanung.

Alle Probleme, die uns gemeldet werden, werden zunächst kategorisiert (z.B. Schweregrad und Wahrscheinlichkeit) und wir versuchen, das Problem zu reproduzieren, was die weitergehende Untersuchung sehr erleichtert. Die Suche nach der genauen Ursache, ohne zu wissen, wo man suchen muss, ist extrem zeitaufwändig. Etwas zu ändern, um ein Problem zu beheben, kann außerdem ein neues Problem an anderer Stelle erzeugen.

„Von Spielern gemeldete Probleme sind wie ein Puzzle, bei dem wir die fehlenden Teile herausfinden müssen, und sobald wir das vollständige Bild haben, schicken wir es zur Lösung an das Produktionsteam. Dieser Prozess beinhaltet auch die Suche nach praktikablen Umgehungsmöglichkeiten („workarounds“) für die Spieler, wo dies möglich ist.“

Aus diesem Grund gibt es vor der Veröffentlichung eines jeden Spiel-Updates eine Validierungsphase, in der sowohl die einzelnen Fehlerbehebungen als auch das Spiel-Update als Ganzes getestet werden. Treten dabei Probleme auf, schlägt die Validierung fehl und wir müssen diese Probleme zunächst beheben.

Um euch einen detaillierten Einblick zu geben, welche Schritte vom Finden eines Problems bis zur Veröffentlichung eines Fixes unternommen werden, arbeiten wir derzeit an einem separaten Blog. Bleibt dran!

Wie wir gerade festgestellt haben, dauert es seine Zeit, ein Problem zu beheben und ein Update zu veröffentlichen. Gibt es mögliche Ausnahmen von diesem Prozess, z.B. den so genannten Hotfix?

Hotfixes sind möglich, aber nur für einzelne, sehr spezifische Fixes mit hoher Priorität. Diese müssen ebenfalls eine Validierung durchlaufen, aber wir können den Prozess beschleunigen (z.B. werden bestimmte Validierungsteams nicht benötigt, wenn nichts geändert wird, was für ihr spezifisches Team relevant wäre), da es deutlich weniger zu prüfen gibt. Generell – vorausgesetzt, das Problem kann reproduziert und schnell behoben werden – könnten wir einen Hotfix in 4 bis 7 Tagen veröffentlichen, falls nötig.

Wir haben in der Vergangenheit verschiedene Playtests durchgeführt, von technischen Tests bis hin zu Tagebuchstudien. In welcher Funktion ist die QA an der Vorbereitung, Überwachung und Nachbereitung/Zusammenfassung beteiligt?

Genau wie bei den Versionen, die für jedes Spiel-Update und jeden DLC-Release vorbereitet werden müssen, müssen wir auch die Versionen für alle Playtests überprüfen. Die Anforderungen sind natürlich weniger streng, kleinere Bugs und Platzhalter-Assets sind daher kein Dealbreaker. Wir führen immer noch grundlegende Checks durch, um sicherzustellen, dass die Version stabil ist und die Mechaniken funktionieren.

Wir stehen auch in Kontakt mit den anderen beteiligten Teams, z.B. dem User Research Lab in Düsseldorf für die Diary Studies oder dem Team, das den Registrierungs- und Einladungsprozess für die Technical Tests verwaltet.

Während der Technischen Tests schauen zumindest einige von uns auch in die Foren, manchmal nur um zu lesen, manchmal auch um bei ein paar Themen nachzufragen, und wir erstellen JIRA-Tickets auf Basis der gemeldeten Fehler und gewünschten Verbesserungen.

Wir hoffen, euch damit einige nützliche Einblicke gegeben zu haben, wie unsere internen Prozesse ablaufen und wie viel Zeit manche Dinge in Anspruch nehmen können, was – dessen sind wir uns bewusst – von außen so nicht immer sichtbar ist.

Wenn ihr weitere Fragen an unsere QA-Teams habt, die hier oder im älteren Blog nicht behandelt wurden, könnt ihr diese gerne in den Kommentaren stellen und wir werden versuchen, die Antworten für euch zu finden.