100% Automatisierung oder weiterhin mit Spieletestern zusammenarbeiten, wie bisher, da diese günstiger ist? Das war die wichtigste Fragestellung zu Anfang der Session Automation in the Technically Challenging World of Game Developing.
Sony, Disney Interactive, The Walt Disney Company, Atari und Localize Direct, von diesen Firmen waren QA-Personen vertreten, um das Thema umfassend zu beschreiben und zu diskutieren.
Welche Testautomatisiserungs Frameworks arbeiten heutzutage gut, um die Entwickler zu unterstützenkonnte leider klar beantwortet werden, da es oftmals sehr speziell entwickelte Tools sind die sich die Entwickler wünschen und benötigen. Dennoch wurden einige Softwarepakete genannt die zumindest Teile des Test abdecken können: JUnit und JMeter wurden als sehr sinnvoll genannt, ebenso PHPunit, FlexUnit (Flash) und Robotest (für Webanwendungen).
Crash-Reporting, Scripttesting und weitere „Baby Tests“ werden aktuell noch bei Sony benutzt, allerdings werden aktuell diese Testmechanismen weiterentwickelt und so optimiert, dass vielleicht für die kommende Generation von Konsolen bereits komplett neue, weiter automatisierte und vor allem übergreifende Testtools zur Verfügung stellen wird.
Für das Systemtesting wurde in der Session zudem erneut JMeter genannt, aber auch „Critisism“ wurde als 3rd Party Tool für Crash Reporting empfohlen und „Silenium“ zum Zeigen von sogenannten „HeatMaps“ als sinnvolle Testapplikation genannt.
Ein gutes Motto war: „Start Early, Encourage your developers to write first test code before full code, think about the full workflow before building the application“ – Hintergrund waren hier, bei sehr umfangreichen Games, dass Buildtimes von mehreren Stunden durchaus üblich sind, weshalb erst getestet (Services, DataQuality, Performance, LoadTime, Assets usw.) und erst dann wirklich der Code zusammengestellt werden sollte.
Entwickeler müssten wohl Ihre QA-Massnahmen selbst planen und aufpassen dass die BlackBox Tests vor dem manuellen WhiteBox Testing der Testern durchgeführt werden, ansonsten gäbe es Frust auf allen Seiten, sondern eine vermutlich wahre, aber auch einschrönkende Aussage, da Entwicklern häufig gar nicht die Zeit zum Schreiben (und Planen!) dieser Tests zugestanden wird.
Andererseits gibt es Probleme Testtools bei Entwicklern einzuführen, die noch nie mit solch einer Entwicklungsumgebung gearbeitet haben, auch diesen „kulturellen“ Aspekt sollte man nicht ausser Acht lassen. Der „Automation“-Engineer sollte ausserdem die Brücke zwischen den Programmierern und den Testern bilden und die Tests führen – Zusammenarbeit ist wichtig, niemand ist schuld, gemeinsam muss man eine Lösung finden, wieder also mal ist die Kommunikation der Dreh- und Angelpunkt sämtlicher Prozesse und Projekte (nicht nur IT, siehe Berliner Flughafen, Stuttgart 21 usw.).
Die QA-Maneger gaben zudem zu bedenken dass TimeToMarket, aber auch QualityToMarket sehr wichtige Erfolgsgeheimnisse eines Spieles (Projektes) sind, deshalb müssen Tests auch priorisiert werden, so dass die Bereiche die z.B. ohne UnitTest erstellt werden klar sind und das Spiel nicht unnötig abstürzen lassen, sondern dasselbe höchstens wenig negativ beeinflussen.
Auch der ROI (ReturnOnInvestement) von Tests wurde angesprochen, wichtig dabei scheint vor allem mal wieder die Kommunikation zu und zwischen allen Beteiligten sowie die Darstellung der erhaltenen Testergebnissen/Daten – denn auch wenn automatisierte Tests zu 100% durchlaufen, könnten Produkte dennoch Fehler enthalten und/oder schlecht sein, so dass 100% Automaisierungs-Testergebnis nicht unbedingt heisst ein 100% TopGame zu erhalten, sondern nur das der automasierte Test positiv durchgelaufen ist – man könnte dies auch Awareness Management“ nennen.
Insgesamt war die GDC2013 Session sehr interessant und die Ergebnisse könnten und sollten auch außerhalb der Spieleentwicklung angewandt werden, dies benötigt allerdings eine entsprechend Kommunikation auch zum Gelbgeber, der dafür entsprechende Mittel bereitstellen müßte.
