Vor kurzem hatte ich Gelegenheit, mit Alexei Nelyubov, QA-Direktor von Datcroft Games, zu plaudern. Jetzt arbeiten die Jungs am mobilen MMO Action Pixel Wars, das Projekt befindet sich in der Soft-Launch-Phase. Die Testabteilung begleitete das Spiel in jeder Phase seiner Entwicklung und ich entschied, dass ein guter Artikel über den Hub aus Alexeys Geschichte hervorgehen würde.
Als nächstes kommt die direkte Sprache.
Pixel Wars hat eine lange und schwierige Geschichte. Ausgehend von den Geschäftszielen haben wir 2016 mit der Montage der ersten Prototypen des Spiels begonnen. In Zukunft wurde das Konzept unter Berücksichtigung der sich ändernden Realitäten des Marktes komplett neu gestaltet, und Ende 2018 kamen „Pixel“ ins Softplay. In naher Zukunft ist eine kommerzielle Veröffentlichung des Projekts geplant.
Wer ist im Team?
Der Abteilungsleiter verteilt Aufgaben, ist bei allen Besprechungen anwesend, erstellt Testpläne, legt Prioritäten für Aufgaben fest und fungiert auch als Testanalyst.
Als nächstes gibt es drei erfahrene Mitarbeiter, die seit mehr als einem Jahr die Qualität des Spiels überwachen. Einer von ihnen hat sich kürzlich intensiv mit Autotests befasst - er erstellt Skripte für Fälle mit einem selbst geschriebenen Tool.
Kürzlich hat sich ein junger und vielversprechender Spezialist unserem Team angeschlossen (zuerst kam er zu Schulungen zu uns, dann bekam er ein Praktikum - und jetzt ist er Mitarbeiter), der bereits viele interessante Probleme löst, von der Kartenüberprüfung bis zum Schreiben einfacher automatisierter Skripte. Und bald warten wir auf einen anderen.
Wir haben eine große Flotte von Testgeräten, von alten Telefonen bis hin zu hochmodernen Geräten mit dem neuesten Betriebssystem und der neuesten Funktionalität. Manchmal ist es interessant, einen Fehler nur auf einem Tablet zu erkennen, da es über eine spezielle Festplatte verfügt, und dann zu versuchen, die entsprechenden Bedingungen im Entwicklungsstudio wiederherzustellen.
Welche Aufgaben lösen QS-Spezialisten?
Wie Sie wissen, beginnt das Testen in iterativen Modellen mit dem Abschluss der Erstellung technischer Spezifikationen und des Entwurfs auf hoher Ebene. So funktioniert es bei uns. Wir lesen die technischen Spezifikationen, bevor sie mit der Implementierung beginnen, sehen uns die Layouts neuer Schnittstellen an, überprüfen die grauen Kästchen der Karten und sehen uns die mathematischen Berechnungen in den Dokumenten der Spieleentwickler an.
Zum Zeitpunkt der Implementierung warten wir nicht, bis alle Änderungen in den Master hochgeladen wurden, sondern testen aktiv einzelne Teile der Funktionalität in separaten Zweigen. Möglicherweise fehlen ihnen schöne Grafiken, anstelle eines Zeichens läuft möglicherweise ein rosa Kegel, und anstelle von Bäumen und Büschen stehen graue Fässer auf der Karte. Die Funktionalität können wir aber schon überprüfen.
Es gibt häufige Fälle von Paartests mit einem Entwickler auf seinem Computer - dies spart erheblich Montagezeit. Wenn ein Programmierer normalerweise nur nach der Funktionalität sucht, die er erstellt oder korrigiert hat, und nur nach positiven Fällen, kann der Tester in negativen Fällen sofort Fehler finden und aus Erfahrung wissen, was genau dieser Programmierer in diesem Modul beschädigen könnte. Die Analyse des Einflusses hilft auch: Wenn beispielsweise ein Gildencode regiert, passiert etwas mit der Funktionalität von Freunden. Warum nicht gleich diesen Moment überprüfen?
Wenn alle einzelnen Codeteile, Grafiken, Effekte, Sounds und Lokalisierungen im Master zusammengeführt sind, ist die Zeit für Integration und Systemtests gekommen. Wir schauen uns an, wie neue Funktionen miteinander funktionieren, und führen Massentests mit dem gesamten Team durch. Oft treten hier Fehler wie "Ich fühle mich unwohl" oder "Ich habe kein Interesse" auf, die ebenfalls aufgezeichnet und verarbeitet werden. Wir betrachten nicht nur die funktionalen Eigenschaften, sondern auch das Verhalten des Spiels unter hoher Last, „schlechtem“ Internet und in verschiedenen nicht idealen Umgebungen, wie z. B. einer Busfahrt durch die Stadt oder im Keller eines Geschäftszentrums.
Wie wird die Version akzeptiert?
Und jetzt sind alle offensichtlichen Fehler behoben, alle neuen Dinge sind bereit, das Licht zu sehen. Kann ich auf das Produkt hochladen? Natürlich nicht. Benötigen Sie die Meinung von Vertretern aller Abteilungen und einigen echten Akteuren. Gleichzeitig beginnt die Regression (die Zeit großer Autotests) und die Abnahmeprüfung. Wenn mit dem ersten alles klar ist (wir überprüfen alle Funktionen des Spiels, fügen veraltete Fälle hinzu, fügen neue hinzu, überprüfen sie auch), dann sprechen nur wenige über Akzeptanz. Aber die Sache ist nützlich. Wir senden den Build an den allgemeinen Kanal des Projekts und fordern alle auf, das Spiel ein paar Tage lang „von ihrem Glockenturm aus“ zu spielen und zu bewerten. Es kann sich herausstellen, dass die Spieledesigner das Merkmal der Grube überhaupt nicht mit Einsätzen repräsentierten, obwohl alles gemäß der Beschreibung und den Layouts durchgeführt wurde und Marketing erforderlich war Ein weiterer Skin des Kriegercharakters für die Aktion im sozialen Netzwerk. Wenn alle Wünsche berücksichtigt werden, gehen wir zum Produzenten, der Hauptperson des Projekts, er gibt die Freigabe, und dann beginnt der Prozess des Hochladens der Version auf das Produkt. Die Aktion dauert eine halbe Stunde ungefähr eine Stunde.
Wenn alles fertig ist, entfernen wir nicht sofort die Platte der professionellen Arbeit. Zuerst müssen Sie sicherstellen, dass die Bewertungen gezogen werden, Zahlungen ausgeführt werden, Spiele gestartet werden und neue Funktionen für die Spieler verfügbar sind.
Als nächstes beginnt der Prozess von neuem.
Noch ein paar Fakten
Um ein Spiel zu testen, muss es häufig nicht gestartet werden. Es gibt eine Mechanik, in der einige Parameter geändert wurden. Großartig, laden Sie das neue Repository herunter, sehen Sie sich die entsprechende XML-Datei an und schließen Sie die Aufgabe. Manchmal wollen Fehler nicht wiederholt werden. Zum Beispiel spielte einer der Partner in unserem Projekt in der U-Bahn, zu diesem Zeitpunkt klingelte sein Telefon und das Internet von 3g wechselte zu WLAN ohne Zugang zum globalen Netzwerk. Gleichzeitig hatte das Gerät keinen Platz mehr und der Akku war überhitzt. Aber wir haben keine nicht reproduzierbaren Fehler, es gibt solche, zu denen die Hände noch nicht gelangt sind.
Natürlich kommt es vor, dass Bugs auf dem Prod rauskommen. Und wenn Benutzer einen gefunden haben, haben wir ihn höchstwahrscheinlich auch gefunden. Es hat nur eine niedrige Priorität oder Reproduzierbarkeit, daher wurde der Fix um zwei Monate verschoben.
Es ist selten, aber es beweist einem Programmierer oder PM, dass ein Fehler ein Fehler ist und sofort behoben werden muss. Zum Beispiel können Sie auf den Karten in die sichere Zone des Feindes gehen. Ja, Sie können dort nicht angreifen, aber dies ist eine großartige Möglichkeit, die Gesundheit wiederherzustellen und den Feind zu überfallen. Er hat bewiesen - sie reparieren es. Nein - suchen Sie nach überzeugenderen Argumenten. Argumente im Stil von „cool“ oder „Ich mag nicht“ werden nicht akzeptiert, konkrete Beispiele mit konkreten Konsequenzen sind erforderlich.
Manchmal mussten wir Verbindungsabbrüche testen und rannten zum Balkon im Büro, bis der Router eine „schlechte“ Interneteinstellung hatte.
Um ein vollständiges Netzwerk zu simulieren und die Anwendung unter solchen Bedingungen zu testen, läuft der Tester speziell mit einem Telefon durch ein überfülltes Einkaufszentrum.
Viele Fehler werden abgefangen, wenn Sie die Verbindung trennen und schnell etwas wechseln. Hier ist die Geschwindigkeit der Bänder auf dem Bildschirm wirklich wichtig. Zum Beispiel fanden sie einen völlig nicht offensichtlichen Fehler: Wenn Sie schnell die Klassen und Skins von Charakteren wechseln, haben Sie am Ende einen Bogenschützen, der einen Schild oder einen Krieger mit einem Zauberstab hält.
Vielen Dank für Ihre Aufmerksamkeit! Ich hoffe, Sie wollten mehr über den Testprozess erfahren.