Daniel Börgers agido GmbH

„Nicht alle Tests und Prüfungen eignen sich für die manuelle Ausführung.“

Angi Mathea agido GmbH

„Anvisierte Wunschvorstellung war, für jeden Test bei dessen Aufruf festzulegen, auf welchen Plattform-Browser-Kombinationen, für welche Sprachen und für welche Domänen dieser laufen soll.“

Dennis Rieks agido GmbH

„Bei der Suche nach dem richtigen Automatisierungsframework gingen wir nach dem Pyramid Approach vor.“

Insbesondere im agilen Umfeld mit kurzen Releasezyklen oder Continuous Delivery ist ein automatisierter Test fast unabdingbar. Hier ist es ohne immensen Testaufwand unmöglich, für jedes Release einen kompletten manuellen Regressionstest zu realisieren. JUnit-Tests haben für die Komponententests bereits vielfach Einzug gehalten. Geplante automatisierte Oberflächen- und Behaviour-Tests sind dagegen eher die Ausnahme.

Das strategische automatisierte Testen fristet in der Softwareentwicklung vielfach noch ein Schattendasein. Dabei ist es für wiederholbare Smoke- und Regressionstests sehr sinnvoll. Außerdem eignen sich nicht alle Tests und Prüfungen für menschliche Wahrnehmung und menschliches Verhalten, also für die manuelle Ausführung. Ungeeignet sind z. B. Prüfungen, bei denen Texte verglichen werden müssen, insbesondere wenn diese nicht in der Muttersprache sind oder darüber hinaus noch über ein anderes Alphabet verfügen. Auch wenn innerhalb eines großen Menüs ein Punkt fehlt oder Überschriften zwar vorhanden sind, aber den falschen Text haben, sind dies Punkte, die einem menschlichen Betrachter vermutlich nicht auffallen – wenn er nicht ausgerechnet danach sucht. Bei Anbietern automatisierter Testtools kommt das automatisierte Testen gerne wie eine Lichtgestalt daher. Entsprechend hochgeschraubte Erwartungen bauen sich auf.

Unsere Anwendung läuft aktuell auf verschiedenen Plattformen (Multiplattform, Android/iOS, Desktop/Mobile) in zehn Übersetzungen (Multi Language) und auf vier unterschiedlichen Domänen (Multi Domain, COM Host, türkischer Host, brasilianischer Host, russischer Host). Anvisierte Wunschvorstellung war, für jeden Test bei dessen Aufruf festzulegen, auf welchen Plattform-Browser-Kombinationen (1 – x), für welche Sprachen (Angabe der zu prüfenden Sprachen, 1 – y) und für welche Domänen (1 – z) dieser laufen soll. In der vollen Ausprägung muss jeder Test x*y*z-mal laufen.

Wie alles begann

Folgende Ausgangssituation liegt vor: Für die vielen Workflows im Backend gibt es Unit-Tests. Improvements werden mit Features abgesichert, sodass sie leicht abgeschaltet werden können. Die Überprüfung der Anforderungen des Kunden bezüglich Aussehen und Verhalten der Anwendung wird manuell durchgeführt. Hierfür werden vom Kunden in den Implementierungstickets zusammen mit dem Entwickler Anforderungen und Abnahmekriterien definiert. Diese lassen sich von den Testern mit einem eigenen Schema in einen Testplan überführen, der manuell ausgeführt wird. Dieses Schema gibt Richtlinien für den manuellen Test vor, die neben explorativen Anteilen abgedeckt werden müssen. Beurteilt wird dabei neben der Spezifikation der Test für verschiedene Äquivalenzklassen, die Usability, das Design der Oberfläche und die Integration in das Gesamtsystem. Es gibt zurzeit keine automatisierten Tests, keine Last- und Performancetests und keine Penetrationstests.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 11.16 - "Automatisiertes Testen"

Alle Infos zum Heft
285704Automatisch, praktisch, gut
X
- Gib Deinen Standort ein -
- or -