Leider wird die Rolle des QA-Managers noch immer als die weniger erreichbare QA-Position im Vergleich zu der eines QA-Engineers angesehen. In diesem Blogbeitrag möchte ich darauf eingehen, dass die manuelle Qualitätssicherung nicht nur eine benutzerzentrierte, sondern auch eine technische Art des Testens ist - auch wenn sie möglicherweise nicht die Entwicklung automatisierter Tests beinhaltet.
Die folgenden Fakten beziehen sich auf meine Erfahrungen bei Project A und deren Unternehmen, bei denen wir die Methode des Gray-Box-Tests anwenden.
Wenn es darum geht, ein neues Feature oder einen Bugfix zu testen, kann der geänderte Code nicht nur mit der Black-Box-Testmethode getestet werden, die im Wesentlichen nur die In- und Outputs berücksichtigt, sondern auch mit einer Methode namens Gray-Box-Testing. Gray-Box-Tests berücksichtigen auch Dinge, die beim Jonglieren mit den Ein- und Ausgängen passieren.
Einige Leute mögen sich fragen, warum es wichtig ist, dies zu berücksichtigen, wenn die Ergebnisse wie erwartet erscheinen. Aber man sollte vorsichtig sein, denn es könnte sich auch um Koinzidenzen handeln. Selbst wenn eine Ausgabe korrekt erscheint, kann die Art und Weise, wie die Ausgabe erzeugt wird, falsch sein und nicht so, wie sie vermutet wurde. Der einzige Weg, dies herauszufinden, ist die Analyse und Beobachtung des Systemverhaltens.
Im folgenden Abschnitt werde ich etwas ausführlicher auf Tools eingehen, die für das Gray-Box-Testing verwendet werden können, wobei der Schwerpunkt auf Debugging-Problemen liegt. Die Tools können aber auch für den Feature-Test eingesetzt werden.
Der Hauptgedanke beim Gray-Box-Testing ist es, herauszufinden, warum ein Problem existiert, d. h. was das Problem verursacht. Es gibt mehrere Tools, die diese Methode des Funktionstests unterstützen, wie z.B.:
Browser-Entwicklertools wie Chrome oder Firefox
Die Browser-Entwicklertools unterstützen Dich bei Informationen über Javascript-Fehler, Cookies oder API-Anfrage-/Antwortdaten.
Interne und externe Logging-Tools wie New Relic
Logging-Tools protokollieren alle Arten von Fehlern, die analysiert werden können und helfen den Entwicklern auch, das Problem besser zu verstehen.
API-Dokumentation und Testwerkzeuge wie Swagger
API-Testwerkzeuge werden verwendet, um die reine API-Funktionalität ohne den Frontend-Teil zu testen. So können sie verwendet werden, um Probleme auszuschließen, die durch das Frontend verursacht werden.
Deine Systemdatenbanken
Datenbanken sind hilfreich, um Daten zu validieren, die sich z.B. auf Aktionen wie das Speichern, Aktualisieren und Löschen beziehen.
Systemumgebungen
Der Vergleich einer Funktionalität, die Probleme in einer anderen Umgebung mit derselben Produktversion verursacht, kann helfen herauszufinden, ob ein Problem möglicherweise nur mit der Umgebung zusammenhängt.
Dein Wissen über die Produkt- und Systemarchitektur
Ein QA-Manager verfügt über eine große Wissensbasis, wenn es um das Produkt und seine Systemarchitektur geht. Nimm dieses Wissen mit, bewahre es auf und benutze es, wann immer es gebraucht wird.
Im Gegensatz zur Methode des Gray-Box-Testing bezieht sich das Black-Box-Testing nur auf die Probleme selbst und worum es bei jedem Problem geht, aber es beleuchtet nicht die Ursache des Problems. Das bedeutet, dass die Entwickler mehr Zeit und Mühe in die Ursachenanalyse investieren müssen.
Um den Entwicklern so viele Informationen wie möglich über ein Problem zu geben, stellt ein technischer QA-Manager nicht nur Informationen über die Umgebung, die Zeit, die Webseite oder die Schritte zur Reproduktion zur Verfügung, sondern auch Informationen über damit zusammenhängende Fehler oder andere relevante Informationen. Die Browser-Entwicklungswerkzeuge und die internen/externen Logs sind eine großartige Quelle dafür.
Vorsicht: Stelle sicher, dass die angegebenen Fehler wirklich mit dem Problem zusammenhängen. Im Zweifelsfall kann man sie mit der Produktionsumgebung oder jeder anderen Umgebung mit der gleichen Produktversion vergleichen.
Darüber hinaus zeigen die Browser-Entwicklungswerkzeuge nicht nur Javascript-Fehler an oder ob eine Anfrage fehlgeschlagen ist, sondern verfolgen auch Formulardaten, die nicht korrekt an die API gesendet wurden oder Daten, die falsch zurückgegeben wurden.
Diese Praktiken werden höchstwahrscheinlich helfen herauszufinden, ob ein Problem durch das Frontend oder das Backend eines Systems verursacht wird. Manchmal ist es jedoch nicht so einfach herauszufinden, was die Ursache ist. In einem solchen Fall arbeiten die Entwickler eng mit dem technischen QA-Manager zusammen und unterstützen sie oder ihn bei der Analyse.
Bei einigen Features kann es sein, dass das Backend vor Beginn der Frontend-Entwicklung fertig ist - oder dass die Komponente der Website nicht einmal ein entsprechendes Frontend hat. In diesem Fall kann es sinnvoll sein, die Endpunkte der API zu testen, ohne das Frontend zu verwenden. Dies kann z.B. mit Postman, Swagger oder selbst entwickelten Tools erfolgen.
Das Gute daran ist, dass es meist schneller geht, als das Testen über das Frontend. In vielen Fällen spart es jedoch Zeit, Backend und Frontend einfach gemeinsam anstatt einzeln zu testen.
QA-Manager zu sein bedeutet zu wissen, wie die Softwarearchitektur aussieht und wie die Softwarekomponenten zusammenspielen. Einerseits muss klar sein, welche Teile des Produkts direkt von der Code-Änderung betroffen sind und somit getestet werden müssen; andererseits ist es entscheidend zu wissen, was nicht getestet werden muss (da gibt es einen Unterschied). Normalerweise ist es sehr hilfreich zu wissen, wie der Code vorher funktioniert hat, um besser zu verstehen, was sich geändert hat. Auf diese Weise kann ein QA-Manager leistungsfähig sein und sich nicht im Detail verlieren.
Ein Testskript stellt die Dinge nicht in Frage. Ein QA-Manager tut das. Dies ist einer der wichtigsten Werte, die ein QA-Manager einbringt.
Natürlich werden auch Produktmanager diese Dinge in Frage stellen, aber manchmal ändern sich die Anforderungen während der Entwicklung. Gleiches gilt für das Design. Von Zeit zu Zeit sehen Designer nur die einzelnen Komponenten, die sie entwerfen. Aber als Ganzes auf der Website - ob Desktop oder Handy - erscheint sie möglicherweise nicht so benutzerfreundlich wie erwartet.
Ein QA-Manager verbindet Produktmanager und Entwickler. Dazu gehört vor allem die Klärung von Fragen beider Seiten und die Suche über ihrer Lösung. Jeder in dieser Runde sollte offen für Kompromisse sein, um innerhalb eines angemessenen Zeitraums eine Lösung zu finden, die auch in einem angemessenen Zeitraum realisiert werden kann. Für den Fall, dass die Spezifikationen bei Einhaltung des Fälligkeitsdatums nicht eingehalten werden, sollte es ohnehin möglich sein, die aktuelle Version freizugeben, wenn sie funktioniert und dennoch eine Verbesserung für den Kunden darstellt. Durch die Erstellung eines Folgetickets gehen die fehlenden Teile nicht verloren.
Die Organisation umfasst sowohl die Selbstorganisation als auch die Teamorganisation. Die Selbstorganisation überschneidet sich teilweise mit den Prinzipien des praktischen Testens, z.B. zu wissen, was getestet werden muss und was nicht, zu erkennen, welche Tickets zusammen getestet werden können oder ob eine bestimmte Testreihenfolge von Tickets eingehalten werden muss. Einen Überblick über alles zu haben, was zuerst getestet werden muss, kann helfen, sich richtig zu organisieren. Nach der Testphase muss ein verständlicher Testbericht erstellt werden. Es versteht sich von selbst, dass ein QA-Manager auch mit den Prinzipien der Textverarbeitung (auch bekannt als "Organisieren" von Texten) vertraut sein sollte.
Darüber hinaus muss ein QA-Manager möglicherweise auch innerhalb des QA-Teams organisieren. Die Abstimmung mit anderen QA-Mitgliedern über Tickets und Aufgaben kann beispielsweise die Leistung oder den Wissensaufbau des Teams verbessern.
In einigen Unternehmen muss ein QA-Manager vollständig neu anfangen und einen geeigneten QA-Prozess implementieren. Da der QA-Prozess in der Regel auf den Entwicklungsprozess ausgerichtet ist, kann sich entweder der Entwicklungsprozess an den QA-Prozess anpassen oder umgekehrt. Dies hängt von der jeweiligen Präferenz ab. Auf jeden Fall sollte am Ende genügend Zeit für eine ordentliche Testrunde bleiben. Das Schlimmste ist, ein gestresstes QA-Team zu haben, das nicht gründlich testen kann, weil es buchstäblich nicht genug Zeit hat. Dies wird niemandem helfen, ein zuverlässiges und stabiles Produkt zu liefern.
Wenn man Software für eine bestimmte Kundengruppe erstellt, sollte das Team hinter dem Produkt immer versuchen, wie seine Kunden zu denken. Die Erfahrung eines QA-Managers kann dem gesamten Team helfen, das ehrgeizige Ziel zu erreichen, ein Produkt zu entwickeln, das die Bedürfnisse seiner Kunden jederzeit vollständig erfüllt.
trendig
