Manuelles Testen stößt im Bereich des GUI-Testens häufig an Grenzen - die zu testenden Abläufe sind einfach zu zahlreich und zu komplex.
Gleichzeitig sollen die Entwicklungsprozesse agil und flexibel bleiben, wodurch kurze Intervalle bei der Testausführung ohne Kompromisse bei der Testabdeckung notwendig werden.
Dieser Konflikt kann nur mit Testautomatisierung aufgelöst werden. Nur mit automatisierter Ausführung der funktionalen GUI-Tests kann die Testfrequenz bei gleicher Teamgröße deutlich gesteigert werden – das Testing wird skalierbar.
Durch die gesteigerte Geschwindigkeit der Testausführung wird eine höhere Frequenz der Testläufe ermöglicht, wodurch Fehler frühzeitig entdeckt und dadurch kostengünstiger behoben werden können.
Entsprechend ist automatisiertes funktionales GUI-Testen mittlerweile essenzieller Bestandteil des Entwicklungs- und Qualitätssicherungsprozesses moderner GUI-Anwendungen.
Wenn wir von Testautomatisierung sprechen, so stoßen wir als Berater oft auf zwei Vorurteile. Zum einen hören wir von einer Angst, dass automatisiertes Testen die Menschen überflüssig macht. Dies ist natürlich nicht der Fall, die Testaufgaben werden höherwertiger und weniger langweilig-repetitiv. Zum anderen gibt es die Annahme, dass mit Testautomatisierung die Testabdeckung gesteigert wird - auch dies ist natürlich nicht der Fall. Testautomatisierung hilft uns „nur” dabei, Tests schneller und potentiell häufiger auszuführen und diesen Prozess mit unserer Continuous-Integration-Pipeline (CI) zu verbinden.
Gesucht ist also Toolunterstützung für die Testautomatisierung, um diese Höher, Schneller, Weiter umzusetzen.
Die folgenden Anforderungen an Testautomatisierungstools begegnen uns in unserer täglichen Praxis regelmäßig:
Flache Lernkurve
- Intuitiv bedienbare Oberfläche
- Die Spezifikation von Testfällen soll im BDD*-Stil erfolgen, d. h. durch textuelle Beschreibung des gewünschten Verhaltens - so können Tests parallel zur Implementierung der GUI entworfen werden.
- Die Verwendung des BDD*-Stils hat den Vorteil, dass hier eine Verbindung zwischen BDD*-Spezifikation und Code geschaffen werden kann: Das Business kann die BDD*-Specs lesen und verstehen, die Entwickler/Tester ihren Code.
*BDD steht für Behaviour Driven Development. Gemeint ist die anforderungsgetriebene Softwareentwicklung, in der Artefakte aus der Anforderungserhebung bereits die Grundlage für automatisierte Tests bilden.
Erweiterbarkeit
- Durch eine offene Architektur sind umfassende Modulbibliotheken zur Realisierung von fortgeschrittenen Testfällen möglich – ganz ohne proprietäre Sprachen oder Technologien
Stabilität
- Der Zugriff auf Objekte in der GUI ist dank objektbasierter Erkennung tolerant gegenüber kleineren Änderungen.
- Durch bildbasiertes Suchen werden Objekte auf der Oberfläche „erkannt”, ohne sie per X-Y-Koordinate spezifizieren zu müssen.
Integration
- Ein zeitgemäßes Tool muss sich nahtlos in CI/CD-Pipelines integrieren lassen
Ein aktuelles Beispiel für ein Tool, welches diese Anforderungen erfüllt ist "Squish" der Firma froglogic aus Deutschland.
Die Bedienoberfläche ist exemplarisch auf den Screenshots zu sehen.
Die Squish IDE bei der Testentwicklung
Quelle: https://www.froglogic.com/wp-content/uploads/2016/04/squish_bdd_report.png
Ein Squish-HTML-Report
Quelle: https://www.froglogic.com/wp-content/uploads/2015/09/report_75percent.jpg
Fazit
Dieser Beitrag hat gezeigt, dass GUI-Testing zwar eine komplexe Tätigkeit ist - mittels Toolunterstützung jedoch skalierbar wird. Dies bietet Teams einen Hebel, um schneller und in kürzeren Iterationen zu arbeiten - was wiederum die Fehlerkosten deutlich senkt. Allein schon durch diesen Aspekt der sinkenden Fehlerkosten lohnt sich eine Investition in Testautomatisierung.
Tipp: Lernen Sie Squish auf einem unserer kommenden Tool-Breakfasts näher kennen!
Wenn Sie Fragen oder Anregungen haben, oder mehr zum Thema Testautomatisierung im GUI-Test erfahren wollen, kontaktieren Sie uns!
