Die Quality Assurance von „Drakensang: Am Fluss der Zeit“ oder Wie alles noch ein bisschen besser wird.

Im achten von insgesamt 15 Entwicklertagebüchern wollen wir euch die Arbeit unserer Quality Assurance (QA) vorstellen. Sie überprüft alles, was von den anderen Abteilungen kommt – indem sie versucht, es kaputt zu machen. Unsere Tester haben also nur eine Mission – zu zerstören, was andere aufgebaut haben; es zumindest zu versuchen. Das Paradoxe an ihrer Arbeit: Sie freuen sich, wenn sie scheitern.

Aber wie gehen unsere Tester vor, wenn sie das Spiel „kaputt machen“ wollen? Sie tricksen einen eigens dafür vorgesehenen Charakter ins Spiel, der alle Fähigkeiten hat und somit gottgleich ist. Mit dieser Figur spielen sie das Spiel von vorne bis hinten durch, und zwar so, wie es normalerweise kein Spieler spielen würde. Unser Leadtester hat dafür einen schönen Vergleich gefunden: Stellt euch einfach vor, dass einem noch sehr sehr kleinen Kind ein Spielzeug in die Hand gedrückt wird und ihm gesagt wird: Aber Vorsicht! Nicht kaputt machen! Stellt euch jetzt vor, wie dieses noch sehr sehr kleine Kind mit diesem Spielzeug umgehen wird, und ihr wisst, wie unsere Tester mit ihrem Alleskönner an unser Spiel rangehen. Und genau so, wie qualitativ hochwertiges Spielzeug auch den größten Trotzattacken eines zerstörungswilligen Kurzhalsmonsters widersteht, muss ein perfekt funktionierendes Computerspiel gegen sämtliche Kniffe, Tricks und Angriffe des Supercharakters gefeit sein.

Nun geht es also los. Unsere Tester bekommen das Testgerüst oder spezielle Aufgaben, wie zum Beispiel: Kontrolliere alle neuen Monster-Icons! Der jeweilige Tester geht dann ins Spiel und prüft seinen Bereich. Wenn er also die neuen Monster-Icons testen soll, holt er sich alle Monster heran und schaut, ob die Icons vollständig sind und funktionieren. Bei uns wird demnach sehr manuell getestet. Wir profitieren vor allem von Manpower, denn es arbeiten sehr viele Tester an „Drakensang: Am Fluss der Zeit“. Was der eine vielleicht mal übersieht, findet der nächste. Es gibt durchaus auch automatische Testmethoden, aber die eignen sich vor allem für Spiele, in denen immer dasselbe passiert. Bei einem so komplexen Spiel wie unserem sind sie eher nicht angebracht.

Unsere Abteilung Quality Assurance arbeitet mit einer Bugdatenbank. Wie schon erwähnt, ist es neben dem routinierten Abarbeiten des Testgerüsts eine Aufgabe unserer Tester, das Spiel so zu spielen, wie kein vernünftiger Mensch es normalerweise spielen würde – und es muss trotzdem funktionieren. Wenn sie dabei etwas Auffälliges finden, schreiben sie dazu einen Bug, wo geschildert wird, worum es geht. Den tragen sie dann in die Bugdatenbank ein.

Bei den Bugs gibt es vier unterschiedliche Kategorien. Zum einen sind da die severe (schweren), die sogenannten A-Bugs. Die sind sogar im Vertrag festgeschrieben, wo verfügt wird, dass ein Projekt nur soundso viele A-Bugs enthalten darf. Solche A-Bugs hat man, wenn das Spiel abstürzt oder zu einem Blocker führt. Ein Blocker wäre zum Beispiel ein bestimmtes Item, das man zwingend aufnehmen muss, um weiter zu kommen, aber nicht aufheben kann. Dann gibt es die sogenannten B-Bugs. Das sind Dinge, die hauptsächlich in Questen auftauchen. Dazu gehört zum Beispiel, dass die versprochene Belohnung ausbleibt oder dass der Spieler keine Erfahrungspunkte bekommt. Das ist lästig und enttäuschend, führt aber zumindest nicht dazu, dass das Spiel nicht mehr spielbar ist. Die dritte Kategorie sind die C-Bugs. Die sind meistens grafischer bzw. technischer Natur. Und zu guter Letzt sind da noch die D-Bugs. Da geht es um kleine nice ideas, wenn zum Beispiel jemand der Meinung ist, dass an einer bestimmten Stelle noch ein Baum mehr stehen sollte. D-Bugs sind darum auch eher Ansichtssache.

Vereinfacht gesagt gibt es also die klassischen Bugs, die auch gleichzeitig die schwersten sind: Unser Tester geht ins Spiel rein, fasst etwas an und das Spiel crasht sofort. Dann sind da die spezielleren Käfer. Einen solchen gab es auch in unserem Spiel: Ein Grafiker hatte an den Animationen rumgespielt. Die Folge – wenn man nun ein Monster schlug, knackte es einfach in der Mitte durch. Das sah ziemlich brutal aus und war natürlich auch mehr als unrealistisch. Unsere Bugdatenbank reicht also von den einfachsten Dingen – du möchtest eine Pflanze pflücken und das geht nicht – bis hin zu wirklich gravierenden Problemen – du pflückst die Pflanze und das Spiel bricht zusammen.

Je nach Schweregrad muss der Bug entweder so schnell wie möglich bekämpft werden oder man kann ihn noch eine Zeit lang ungehindert im Spiel herum krabbeln lassen, ohne dass er größeren Schaden verursacht. Dafür gibt es in der Bugdatenbank eine Prioritätenlisten von urgent (dringlich), über medium (mittel) bis low (niedrig). Nachdem der Bug dann von den anderen Abteilungen gefixt wurde, wird er wieder überprüft. Unsere Tester müssen sich also alles immer und immer wieder anschauen, ob sich nicht doch noch irgendwo ein Bug versteckt. Dabei tritt irgendwann das Problem auf, dass man als Tester eine Art Tunnelblick bekommt, weil man hundertmal die gleichen Sachen spielt. Deswegen holen wir uns immer mal wieder neue Leute zum Testen heran, die noch unbeeinflusst sind und das Produkt noch gar nicht kennen.

Fast täglich gibt es eine neue Version, in der neue Sachen getestet oder Sachen, die repariert wurden, noch einmal überprüft werden müssen. Dann müssen unsere Tester wieder das ganze Spiel von hinten bis vorne durchspielen. Bei „Drakensang: Am Fluss der Zeit“ dauert es allein mehr als sieben Stunden, um bloß einmal durch die reine Hauptquest „zu rennen“.

Aber wie können wir am besten dafür sorgen, dass wir am Ende möglichst wenige Bugs und ein relativ stabiles Spiel haben? Zum einen ist es ganz wichtig, dass wir in der Planungsphase des Projekts auch schon genau festlegen, was wann wo und wie eingebaut werden soll. Dafür entwickeln wir einen sogenannten Milestone-Plan. Wir haben jeden Monat einen Milestone, also eine Deadline, bis zu der eine bestimmte Anzahl von Dingen fertiggestellt sein muss. Das heißt auch, dass diese Dinge dann testbar sein müssen. Diese Milestones sind gute Anhaltspunkte für uns, wenn wir sehen wollen, wo wir in der Produktion stehen. Auch unsere Tester orientieren sich an ihnen.

Außerdem gibt es in jeder guten Produktion am Ende eine Zeitspanne, die alleine dafür reserviert ist, all das zu fixen, was während der Produktion auf der Strecke geblieben ist – und natürlich haben wir die bei „Drakensang: Am Fluss der Zeit“. Was sich dann ebenfalls ändert, ist die Anzahl der Tester. Im Produktionszyklus arbeiten mehr Leute an der Produktion und weniger sind mit dem Testen beschäftigt. Dieses Verhältnis kehrt sich immer mehr um, je näher das Produktionsende rückt, was ja nur logisch ist, denn je mehr fertig ist, umso mehr muss getestet werden und umso weniger muss hergestellt werden.

Dass die Käferbekämpfung beim ersten Teil von „Drakensang“ so gut funktioniert hat, war aber nicht nur der guten Arbeit unserer Quality Assurance zu verdanken. Daran hatten alle Abteilungen ihren Anteil. Bei „Drakensang: Am Fluss der Zeit“ soll das natürlich auch alles so gut, wenn nicht gar besser funktionieren. Die Voraussetzungen dafür sind denkbar günstig, denn an unserem neuen Projekt arbeiten jetzt noch mehr Leute mit. Und je mehr Augenpaare auf Bugsuche gehen, umso schlechter stehen die Chancen für diese kleinen Missetäter, unentdeckt zu bleiben.

zurück zur Übersicht