Kann man das nicht automatisieren?!
Sich wiederholende Tätigkeiten stoßen auf wenig Gegenliebe bei Developern. Sind dieselben Tasks ein zweites oder drittes Mal auszuführen, wird der Wunsch nach Automatisierung laut. Kurz gesagt: Entwickler hassen manuelles Testen. Viel lieber werden automatisierte Tests erstellt. Automatisiertes Testen ist ein essenzieller Bestandteil moderner Softwareentwicklung, doch wir sind der Meinung, dass manuelles Testen ebenso seine Berechtigung hat. Zum einen ist nicht alles (effizient) automatisierbar, zum anderen bietet die menschliche Komponente beim Testen durchaus Vorteile.
Warum ist manuelles Testen so oft eine Qual?
Werfen wir einen Blick auf einige der Schmerzpunkte und wie diese reduziert werden können:
- Der Testfall ist überspezifiziert
- Der Systemzustand für den Test wird nicht wiederverwendet
- Der Testfall ist in sich repetitiv
Durch das Ausmerzen der Problemfelder wird manuelles Testen zeitgleich kreativer und interessanter und trägt somit auch seinen Teil zum Projekterfolg bei.
Der Testfall ist überspezifiziert
Öffne "die Hauptseite", klicke auf den Button "Registrieren", gib im Dialog "E-Mail" den Wert "user@foo.bar" ein, im Feld "Name" den Wert "User", im Feld Passwort "test123!!!", klicke "Speichern".
Worin besteht das Problem?
Der Vorteil eines manuellen Tests gegenüber einem automatisierten besteht darin, dass er von einem Menschen - der mitdenken kann - ausgeführt wird. Ist wie im aktuellen Beispiel, bereits alles sehr genau vorgegeben, drängt sich die Frage auf: „Wozu benötige ich dann eine Person zur Ausführung des Testfalles?“ Darüber hinaus wird so überspezifiziert möglicherweise nur ein extrem schmaler Pfad abgedeckt und damit eigentlich das Potenzial des manuellen Tests verschwendet.
Wie finden wir eine Lösung?
Gib dem Tester mehr Freiheit! Mehr Entscheidungsspielraum ermöglicht es dem Tester sich selbst Gedanken über den Anwendungsfall zu machen und seiner Kreativität freien Lauf zu lassen. Gleichzeitig helfen Testfälle in Checklisten dabei, dass nichts Wichtiges vergessen wird. Der Tester kann sich von den Hinweisen inspirieren lassen.
Eine bessere Formulierung könnte z.B. wie folgt lauten:
Registrierung verifizieren.
- Felder sind sinnvoll beschrieben - was wird als Eingabe erwartet?
- Eingabewerte verhalten sich korrekt bei leer, ungültig, langen Inhalte, Sonderzeichen, ...
- Validatoren sind aussagekräftig, Pflichtfelder sind ersichtlich
Nachteil dieses Lösungsansatzes:
Man büßt die 100%ige Verifikation aller Edge Cases ein. Einmal wird der Tester an diese Fälle denken, ein anderes Mal wird er andere ausführen. Die Möglichkeit den Testfall stupide durchklicken zu können fällt weg.
Vorteil dieses Lösungsansatzes:
Im neuen Beispiel "Registrierung verifizieren" haben wir einen Test, der leicht zu überfliegen ist, in dem sich der Tester Ideen fürs Ausprobieren holen kann, der ihn aber nicht einschränkt in seiner Kreativität, sein Ziel zu erreichen, das System lahmzulegen.
Der Systemzustand für den Test wird nicht wiederverwendet
Worin besteht das Problem?
Wenn die Software in einen für die Testausführung benötigten Ausgangszustand versetzt wurde, möchte man in diesem Zustand so viele Testszenarien wie möglich abdecken. Das reduziert den Aufwand für die Zustandsherstellung und erhöht damit das Zeitkontingent für tatsächliches Testen. Es ist ärgerlich, wenn man einen Testfall abschließt, nur um zu entdecken, dass der nächste Testfall mit einem einzigen Klick im vorigen Zustand mit abgedeckt werden hätte können.
Wie finden wir eine Lösung?
Es ist schwierig bereits bei der initialen Erstellung der Testfälle den richtigen Ablauf zu finden. Umso schwieriger ist es beim laufenden Erweitern zur Abdeckung von Funktionalitätserweiterungen. Am effizientesten entdeckt man Ineffizienzen im Aufbau bei der Testausführung. Hat man die Möglichkeit die Testfälle zu überarbeiten, zusammenzuführen, zu aktualisieren, zu erweitern, in der Ausführungsreihenfolge zu verschieben etc. kann im Zuge der Testausführung der Zustand der Tests verbessert werden. Das wird dem Vorteil des mitdenkenden Testausführers gerecht.
Nachteil dieses Lösungsansatzes:
Da sich von Testlauf zu Testlauf die Testsuite verbessern wird, kann nicht exakt der gleiche Testfall bei jedem Release ausgeführt und in Reports über Jahre verglichen werden - aber wo ist das überhaupt realisierbar?
Vorteil dieses Lösungsansatzes:
Eine stetige Qualitätsverbesserung der Tests. Eine abwechslungsreiche und kreative Tätigkeit für den Tester, der im Zuge der Ausführung die Tests optimieren kann.
Der Testfall ist in sich repetitiv
Führe oben genannte Schritte in Dark- und Lighttheme, Deutsch und Englisch, in Chrome, Safari und Firefox aus.
Worin besteht das Problem?
Entweder hinterlässt der Testfall bei der Ausführung den Beigeschmack, dass er kaum wie beschrieben ausgeführt wurde. Oder man schläft bei der vierten von zwölf Permutationen des obigen Beispiels ein.
Wie finden wir eine Lösung?
Durch die Ausführung verschiedener Tests in verschiedenen Varianten werden alle Möglichkeiten stichprobenartig ausgeführt. Einen Test auf Englisch im Dark-Theme auf Safari, einen anderen auf Deutsch in Firefox, beim dritten zwischendurch die Sprache umgeschaltet. Dieses Vorgehen erhöht die Kreativität in der Ausführung bei gleichzeitiger Berücksichtigung verschiedener Umgebungsbedingungen.
Nachteil dieses Lösungsansatzes:
Die 100%ige Testabdeckung in allen Permutationen ist nicht möglich.
Vorteil dieses Lösungsansatzes:
Abwechslung in der Ausführung und implizite Risikoabwägung durch den Tester, welche Kombinationen fehleranfälliger sind und daher eines genaueren Blickes bedürfen.
Fazit
Durch eine stärkere Berücksichtigung der menschlichen Komponente im manuellen Test wird die Tätigkeit des manuellen Testens aufgewertet. Prozesse und Werkzeuge sollen den manuellen Tester unterstützen, aber nicht einschränken. Ohne Ausnützung der menschlichen Vorteile wird der manuelle Tester rasch zu einer teureren, langsameren und fehleranfälligeren Variante eines automatisierten Tests.
Welche Prozesse und Werkzeuge stehen zur Verfügung, um genau diese Unterstützung ohne gleichzeitige Einschränkung der Freiheiten zu gewähren? In weiteren Beiträgen zum Thema werden wir näher auf die oben beschriebenen Problemfelder eingehen und am Beispiel des Testmanagementwerkzeuges Testiny veranschaulichen, wie diese adressiert werden können.
