Human Testing! Warum wir den Menschen in den Mittelpunkt stellen
In den letzten Jahren hat sich ein Wandel in der Softwareentwicklung vollzogen – von klassischen zu agilen Prozessen. Anstatt still vor sich hinzuarbeiten, nehmen Kollaboration und Kommunikation einen hohen Stellenwert ein. Natürlich hat sich somit auch der Softwaretest verändert. Die Sensibilisierung für Qualität ist gestiegen und wurden Testerinnen und Tester am Anfang noch als "Feinde" wahrgenommen, sind sie im Laufe der Zeit gleichwertige Teammitglieder geworden. In Abb. 1 ist einmal grob skizziert, wie sich die Sicht auf die Softwarequalität gewandelt hat.
Ein weiteres wichtiges Thema nimmt hierbei auch die Testautomatisierung ein. Das Thema wird und muss immer intensiver betrachtet werden, da neben der Komplexität und vor allem den schnelleren und häufiger stattfindenden Release-Zyklen und damit verbundenen Regressionstests Qualitätssicherung ohne Testautomatisierung nicht mehr möglich ist. Das Bewusstsein dafür, dass durch Testautomatisierung eine Basis für Qualitätssicherung gesetzt wird, ist vorhanden. Aber genau an diesem Punkt muss auch genauer hingeschaut werden. Denn von anfänglich beinahe 100 Prozent manuellen Tests geht der Trend nun zu 100 Prozent automatisierten Tests. Das führt dann auch teilweise zu abstrusen Aussagen, die uns als Testerinnen und Testern in Projekten immer wieder begegnen:
- Wenn wir alles automatisiert testen, passt das doch!
- Der manuelle Test am Ende kostet uns nur viel Zeit und bringt nichts.
- Bei einem händischen Test fehlt uns zum Sprintende Zeit für die Entwicklung.
- Wir haben doch bereits alles unit-getestet, was bringt uns denn da der manuelle Test noch?
- Keine Tester vorhanden, dann machen wir halt 100 Prozent Testautomatisierung!
Die Gründe für diese Aussagen sind vielfältig. In einem Projekt fehlt schlicht und einfach die Test-Ressource und woanders fehlt die richtige Bewertung für Qualitätssicherung. Bei anderen Projekten sieht man nur noch Automatisierung und verdrängt damit komplett die menschlichen Stärken oder hat einfach eine falsche Vorstellung von Testautomatisierung. Doch im Gegensatz zu Testautomatisierung kann der Mensch während des Tests Vorhersagen treffen, ad hoc entstandenen Ideen nachgehen, Verfeinerungen vornehmen und unterschiedliche Blickwinkel betrachten. Wenn man diese Stärken außen vor lässt, geschieht eine Abwertung des Testenden und die Aussage zur Qualität und Benutzbarkeit des Testobjekts wird unzureichend betrachtet.
Qualitätssicherung nach Elisabeth Hendrickson: Checked + Explored = Tested!
Wenn man einen allumfänglichen Softwaretest erreichen will, sollte man sich an der folgenden Aussage von Elisabeth Hendrickson orientieren: Checked + Explored = Tested [1]. Dabei nimmt der "Checked"-Anteil das Abarbeiten von definierten Testschritten ein, ohne dabei den vorgegebenen Pfad zu verlassen. Dies kann durch klassische Tests geschehen, bei denen Testschritte definiert werden, welche anschließend abgearbeitet werden. Hier lohnt es sich allerdings, wenn diese Aufgabe durch Testautomatisierung durchgeführt wird, sofern dies technisch möglich und sinnvoll ist. Diese automatisierten Tests können so immer wieder ausgeführt werden. Das ermöglicht es Testerinnen und Testern, explorative Testansätze anzuwenden. Damit ist man dann auch bei dem "Explored"-Part in Hendricksons Aussage. Dabei bekommen die Testerinnen und Tester die Chance, sich in die Rolle eines Erforschers hineinzuversetzen und mit unterschiedlichen Blickwinkeln die Software zu betrachten, nichtfunktionale Anforderungen zu prüfen und somit auch Benutzbarkeit, Gebrauchstauglichkeit oder Zuverlässigkeit stärker in den Fokus zu nehmen.
Nachfolgend gebe ich einen detaillierten Einblick, was Testautomatisierung leisten kann, wo ihre Grenzen liegen und warum der Mensch an dieser Grenze dann mehr in den Fokus rückt.
Testautomatisierung – Freud und Leid
Wie schon erwähnt, wird Testautomatisierung favorisiert, um Testfälle zu automatisieren, die ein Abarbeiten von Testschritten darstellen – kurzum ein sogenanntes Checken. Beispiele hierfür sind Eingabe und Validierung von Werten, Prüfung, ob Elemente auf der Benutzeroberfläche vorhanden sind, Abprüfen von vorgegebenen Pfaden. Dabei schafft man eine Basis aus Testfällen, die immer wieder durchgeführt werden können und autark lauffähig sind.
Durch die Integration in eine CI/CD-Pipeline können die Tests durch verschiedene Trigger automatisiert gestartet werden. Dadurch kann eine schnelle und kontinuierliche Rückmeldung von Testergebnissen erlangt werden und es können direkt Rückschlüsse darauf gezogen werden, ob die definierten Prüfungen noch Bestand haben oder durch Neuentwicklungen verletzt werden. Schlagen automatische Tests fehl, lassen sich zeitnah die Gründe untersuchen und die Ursache kann behoben werden. Somit kann Zeit und Geld für die Fehlerbehebung gespart werden, da Fehler frühzeitig erkannt wurden und nicht erst zu einem späteren Zeitpunkt im Softwarelebenszyklus, z. B. beim Kunden, aufschlagen. Außerdem wird durch die kontinuierliche Durchführung von automatischen Tests eine Konsistenz von Testergebnissen sichergestellt und die Vergleichbarkeit der Ergebnisse über lange Zeiträume hinweg gewährleistet.
Doch damit kommt die Testautomatisierung an ihre Grenzen. Zwar lässt sich ein Pool von Regressionstests erstellen, die nicht mehr manuell abgearbeitet werden müssen, aber es lässt sich damit keine vollständige Qualitätssicherung in Softwareprojekten gewährleisten. Es braucht somit auch weiterhin die Rolle des Testers. Zum einen lassen sich durch Testautomatisierung keine neuen Erkenntnisse über die Software gewinnen, da immer wieder dieselben Schritte abgearbeitet werden. Zum anderen denkt eine Maschine nicht und weicht nicht von vordefinierten Pfaden ab. Bei Änderungen in Prozessen, die ad hoc hereinkommen, haben automatisierte Tests nur begrenzte Reaktionsmöglichkeiten, da eine Anpassung an der Definition durch den Menschen geschehen muss. Währenddessen lassen sich diese Änderungen beim manuellen, explorativen Test sofort in die Testabläufe integrieren.
Somit ist eine Beurteilung der entwickelten Funktionen aus Sicht der Endnutzerinnen und Endnutzer und somit Usability-Tests und Abnahmetests allein durch Testautomatisierung nicht möglich. Es kommt hier nicht nur auf die Prüfung einzelner Testschritte an, sondern vor allem auf die menschlichen Sinne: "Was habe ich für ein Gefühl, wenn ich die Anwendung nutze? Wie sieht die Anwendung aus und macht sie das, was der Kunde bzw. Stakeholder erwartet?".
Warum wir den Menschen in den Mittelpunkt stellen
Für Stakeholder bzw. Entscheider ist es schwierig, einem Testreport zu vertrauen, der nur ein Ergebnis in Zahlen darstellt. Deutlich besser lässt sich Vertrauen auf der zwischenmenschlichen Ebene schaffen und dazu wird der Mensch mit seinen Fähigkeiten benötigt – und somit wird für einen Human-Testing-Ansatz plädiert. Im Folgenden erkläre ich, was ich damit meine.
In die Testerinnen und Tester wird das Vertrauen bezüglich der Bewertung der Softwarequalität gesetzt und somit das Vertrauen auf menschliche Stärken. Dabei wird sowohl auf explorative als auch kollaborative Ansätze gesetzt. Diese ermöglichen den Testerinnen und Testern Freiheiten und Kreativität, indem sie sich von starren Vorgaben lösen und über den Tellerrand hinausblicken.
Durch den explorativen Ansatz wird mehr Abenteuer beim Softwaretest ins Projekt gebracht. Eintöniges Abarbeiten von definierten Testfällen tritt in den Hintergrund und die Neugier und der Forscherdrang werden geweckt. Der Software wird intensiver zu Leibe gerückt, um Schwachstellen aufzuspüren und somit aktiv bei der Beseitigung von Abweichungen zu helfen und die Anwendung qualitativ hochwertiger zu machen.
Dabei lassen sich unterschiedlichste Testmethoden anwenden, um neue Testideen zu generieren und neue Erfahrungen zu sammeln. Der Wissensaufbau, der dadurch wiederum gefördert wird, lässt sich direkt bei der nächsten Testsession anwenden. Denn die gesammelten Erkenntnisse ermöglichen es, bei der Prüfung der Anwendung andere Pfade einzuschlagen als nur den Happy Path und vorhandene Funktionalitäten zu hinterfragen.
Und damit wurde auch der Explored-Anteil in Hendricksons Aussage beleuchtet. Eine vollumfänglich getestete Software erhält man durch die Nutzung von Testautomatisierung und durch manuelles, exploratives Testen, bei dem die menschlichen Stärken zum Einsatz kommen (Checked + Explored = Tested). In Anlehnung an Hendricksons Aussage bedeutet dies, dass ein vollständiger Test im agilen Kontext nur durch Human Testing und Testautomatisierung Bestand haben kann. Denn nur wenn diese beiden Komponenten ineinander greifen und durchgeführt werden, wird die Qualitätssicherung als Querschnittsthema im Softwarelebenszyklus wahrgenommen.
Die Testerinnen und Tester und die neue Rolle
Die Art der Betrachtung des Softwaretests und der manuellen Tests muss sich wandeln. Die Darstellung der Testerinnen und Tester als Klick-Monkeys (Personen, die nur Dienst nach Vorschrift machen, ohne selbständig und frei zu denken) ist abwertend und vermittelt ein falsches Bild auf den manuellen Test. Dabei ist es zum einen wichtig, dass dieses Bildnis des Testenden von allen Beteiligten in der Softwareentwicklung nicht mehr genutzt wird. Zum anderen müssen die Testerinnen und Tester ihr Mindset zur Qualitätssicherung in Softwareprojekten erweitern, anpassen oder überdenken, und bei der Arbeit anwenden. Human Testing bedeutet für uns nicht nur, dass der manuelle Test in explorativer Form durchgeführt wird, sondern auch, dass Testerinnen und Tester weitere Funktionen, Aufgaben und Rollen im Team einnehmen, die im Weiteren beschrieben werden.
In der agilen Softwareentwicklung muss jedem bewusst sein, dass Qualitätssicherung jeden Projektbeteiligten betrifft. Dies bedeutet auch, dass das gesamte Team weiß, wie essenziell wichtig die Softwarequalität und deren Umsetzung während der Softwareentwicklung ist. Damit darauf geachtet wird, dass die Test-Aktivitäten auch durchgeführt werden, muss jemand die Verantwortung dafür übernehmen. Da die Testerinnen und Tester die entsprechenden Fähigkeiten mitbringen, ist es von Vorteil, dass diese Verantwortung bei der Tester-Rolle liegt. Das bedeutet ebenfalls, dass die Testerinnen und Tester von Anfang an im Projekt eingesetzt werden, da von Anfang an und auf allen Ebenen im Softwarezyklus die Qualitätssicherung betrachtet werden muss. Der Test ist ein essenzieller Bestandteil der Softwareentwicklung. Dies lässt sich auch gut in Abb. 2 – dem Softwarelebenszyklus nach Dan Ashby – nachvollziehen [2].
Neben der Verantwortungsrolle erhält die Testerin bzw. der Tester ebenfalls die Rolle eines Coaches im Team. Das beinhaltet die Weitergabe von dem Fach- und Methodenwissen, um das einheitliche Verständnis bezüglich Qualitätssicherung zu schärfen, die Kommunikation zu optimieren und den Erfahrungsaustausch voranzubringen. Dabei sind kollaborative Methoden zu favorisieren wie z. B. Pairing oder Mob Testing.
In agilen Softwareprojekten ist ein weiterer Punkt notwendig, um als Testerinnen und Tester weiterhin bestehen zu können: spezielle Softskills.
Selbstorganisation und Gewissenhaftigkeit müssen noch ausgeprägter vorhanden sein als beim klassischen Test, da z. B. explorative Tests nicht vordefiniert sind, sondern eigenständig durchgeführt und dokumentiert werden müssen. Dabei hat die Zeiteinteilung für Testdurchläufe und selbständige Priorisierung von Testsessions eine ebenso hohe Bedeutung wie der vom Projekt vorgegebene Dokumentationsgrad.
Des Weiteren werden Kommunikation und Teamfähigkeit benötigt. Das beinhaltet zum einen, innerhalb des Teams den Fortschritt im Test sowie gefundene Abweichungen zu kommunizieren und Erfahrungen auszutauschen. Zum anderen ist es wichtig, einen kontinuierlichen Austausch über Ergebnisse sowie Erkenntnisse zum Kunden bzw. zu Stakeholdern zu gewährleisten. Letztendlich wird durch die Einschätzung der Softwarequalität der Testerinnen und Tester das Vertrauen sowohl in die Anwendung als auch in die Leistung des gesamten Entwicklungsteams aufgebaut.
Somit werden die Testerinnen und Tester zum Kleber im Team – durch die Verantwortungs- und Coach-Rolle bezüglich Softwarequalität, aber auch als Kommunikationsschnittstelle zwischen den Beteiligten.
Eine weitere Eigenschaft ist Lernbereitschaft, um sich neues Wissen aus allen Bereichen der Softwareentwicklung und auch Domänen-Wissen anzueignen. Das bedeutet auch, dass man sich von den Silo-Denkweisen lösen muss und sich z. B. auch mit Programmieren auseinandersetzt. Dies dient in erster Linie dazu, ein Verständnis für die Komplexität und die Aufgaben zu bekommen und nicht, Entwicklungsaufgaben zu übernehmen. Es geht darum, neugierig zu bleiben, neue Dinge erlernen zu wollen und nicht in einer Silo-Denkweise stecken zu bleiben. Das lässt sich gut unter dem Begriff Growth Mindset zusammenfassen.
Quintessenz
- Neben der Testautomatisierung wird es auch weiterhin menschliche Testaktivitäten geben.
- Human Testing bringt die menschliche Komponente in den Vordergrund und entfernt sich vom Bild des "Klick-Monkeys".
- QA/Testing betrifft das gesamte Team, es wird weiterhin Tätigkeiten geben, die nicht automatisiert werden können.
- Qualitätsbewusstsein ist eine Haltung des Teams.
- In der QA kann bewusst die menschliche Stärke gegenüber der Maschine genutzt werden.
- Human Testing + Testautomatisierung = Agile Testing.
Neue Aufgabengebiete, Rollen und Fähigkeiten gibt es für die Testerinnen und Tester, doch das Mindset zur Qualitätssicherung und Sichtweise auf das manuelle Testen müssen sich ändern. Der Mensch und seine spezifischen Fähigkeiten stehen dabei im Mittelpunkt – die Betrachtung der Rolle muss wertschöpfend sein und das Bild eines Klick-Monkeys muss verschwinden. Denn nur dadurch kann der Blick auf die Rolle des Testers verbessert werden. Und auch die Testerinnen und Tester müssen dabei lernen, die neuen Aufgaben zu meistern. Ein nötiger Schritt dafür ist die Bereitschaft, seinen Wissenshorizont zu erweitern und sich persönlich weiterentwickeln zu wollen.
