Das Angebot für Testautomatisierungstools ist überraschend groß, wenn man bedenkt, dass es sich bei der Testautomatisierung schon um eine ältere Disziplin handelt Seit den ersten kommerziellen Tools werden in den letzten Jahrzehnten Open-Source-Tools immer beliebter. Mittlerweile geht der Trend immer mehr in Richtung Test Automation as a Service (TAaaS). Die meisten Tools verwenden jedoch die gleiche Testautomatisierungsschnittstelle. Für Web-Anwendungen ist dies Selenium, für mobile Anwendungen Appium. Das ist doch gut, oder? Ja, es ist sehr gut, wenn man eine gemeinsame Testschnittstelle hat, aber wenn sie nicht funktioniert, dann ist das schlecht. Eine Testschnittstelle ist die Schlüsselkomponente der Testautomatisierung – sie aktiviert oder deaktiviert die Testautomatisierung, d. h., sie macht die Testautomatisierung einfach oder schwierig.

Design for Testability

Das obige Bild stammt aus einem modellbasierten Testseminar an der Tampere University of Technology 2008. Es zeigt die Rolle der Testschnittstelle in einem Automatisierungs-Stack. Die Systemmodellierungsschicht kann durch ein beliebiges CI/CD-, TAaaS-, Test-Management-Tool oder ähnliches ersetzt werden; die Testschnittstelle als Hauptkomponente bleibt jedoch dieselbe. Die Testschnittstelle ist Voraussetzung für Design for Testability. Versuchen Sie, Tests von Google-, Apple- oder Microsoft-Produkten zu automatisieren, und Sie werden verstehen, was ich meine: Testautomatisierung kann schwierig und komplex gemacht werden, wenn sie nicht ordentlich unterstützt wird. Google ermöglicht beispielsweise Browser-Testautomatisierung mit einer Testschnittstelle namens ChromeDriver. Unglücklicherweise wird das Release der neuesten Version von ChromeDriver zusammen mit einem Chrome-Release erzwungen, selbst wenn Probleme vorhanden sein sollten, die bestehende Testfälle fehlschlagen lassen. Ich war sehr froh, als das Playwright-Team von Microsoft microsoft/playwright veröffentlichte – ein Schritt in die richtige Richtung in Sachen Design for Testability durch einen Softwaregiganten. Gute Arbeit, Microsoft! Ohne Design for Testability bleibt die Entwicklung von Softwareprodukten vergleichbar mit der Art und Weise der Produktion von Autos in der Automobilindustrie vor etwa 60 Jahren. Die Testschnittstellenreife war der Schlüssel zum Erfolg der Auto(no)mationsaktivitäten und wird es auch in Zukunft sein.
Softwareprodukte aus den 2020ern werden immer mehr Komponenten der Künstlichen Intelligenz (KI) und des Maschinellen Lernens (ML) integriert haben. Diese zu testen wird noch anspruchsvoller als es bei heutigen Softwareprodukten der Fall ist. Wenn die Testbarkeit nicht ordentlich unterstützt wird, wird die Testautomatisierung in Zukunft Probleme haben, KI-/ML-Features aufeinander abzustimmen, um sie zu testen. Ebenfalls interessant ist die Entwicklung der starken KI innerhalb der nächsten Jahrzehnte, die neue Herausforderungen für Prüfungen, aber auch neue Möglichkeiten mit sich bringt. Unternehmen, die fortschrittliche Softwareprodukte entwickeln, müssen die Verantwortung für die Testbarkeits-Features in ihren Backlogs übernehmen. Design for Testability ist in der Softwareindustrie genauso wichtig, wie es vor etwa 70 Jahren in den Anfangstagen der Entwicklung elektronischer Ausstattung war. Der Begriff Design for Testability und seine Bedeutung sind in der Agile-Ära etwas verblasst.

Architektonische Aspekte der Testautomatisierung

Ein Steuerungstool für die Testausführung und eine Testschnittstelle (Bibliothek) sind separate Komponenten, die auf einer lokalen Workstation oder einem Teil einer TAaaS-Lösung installiert werden können. Ich verwende Robot Framework, das hier in das TAaaS-System integriert ist, um die architektonischen Aspekte zu erklären, die detaillierter betrachtet werden müssen. Robot Framework ist zusammen mit der Selenium-Bibliothek bei Testautomatisierungen für Web-Anwendungen das weitverbreitetste Open-Source-Framework. Es bietet ein Framework, mit dem Sie Ihre Testautomatisierung auf verschiedene Bereiche erweitern können, indem Sie Open-Source-Bibliotheken verwenden oder Ihre Erweiterungsbibliotheken implementieren, wie in der nachfolgenden Abbildung veranschaulicht.

Sie werden sich fragen, warum ein Testautomatisierungssystem so komplex sein muss. Kurz gesagt: Verschiedene Anliegen müssen getrennt sein, da Sie den Automatisierungsaufwand für verschiedene Zielsysteme, Plattformen und ihre Varianten nicht vervielfachen möchten. Heutzutage generieren Anwendungsentwicklungsframeworks iOS-, Android- und Webanwendungen aus demselben Quellcode, so dass der Anwendungsfluss beinahe derselbe ist. Testautomatisierungsingenieure müssen aber immer noch verschiedene Testschnittstellen bei verschiedenen Plattformen verwenden, sogar bei verschiedenen Browsern. Die eine magische Testschnittstelle für alle gibt es leider nicht. Natürlich verstecken TAaaS-Anbieter diese ganze Komplexität hinter den Kulissen, aber die Unterstützung all dieser Kombinationen mit begrenzter Testbarkeitsunterstützung ist anspruchsvoll.
Die Testautomatisierung für Apps für Mobilgeräte ist hier ein gutes Beispiel. Apps für Mobilgeräte waren früher überwiegend native Apps. Heutzutage gibt es aber immer mehr hybride Apps, die sowohl native als auch WebView-Objekte beinhalten. Bei der Automatisierung von Testfällen muss ein Testautomatisierungssystem die Testschnittstellen sowohl der nativen App als auch der Webanwendung verwenden, abhängig vom Objekttyp, der getestet wird. Natürlich sind Testschnittstellen für native Apps von iOS und Android verschieden. Leider gibt es sogar komplexere Szenarien, bei denen die WebView-Objektquelle verborgen ist. In diesem Fall besteht die einzige Lösung darin, die Computer-Vision-basierte optische Zeichenerkennung (OCR) zu verwenden, die in der Testschnittstelle für Apps für Mobilgeräte integriert ist. Viele der verfügbaren OCR-Bibliotheken sind aufgrund von Leistungsproblemen zu langsam für Testautomatisierungszwecke. Bitmaps lassen sich schnell verwenden, aber die Verwaltung von hunderten oder sogar tausenden Referenzbildern ist zeitaufwendig, und oft kommt es zu Problemen mit der Ausfallsicherheit von Bitmap-basierten Ansätzen. Eine Testautomatisierungsarchitektur sollte in einer Weise errichtet sein, dass die Lösung skalierbar, schnell und zuverlässig ist und dass die unterschiedlichen Testschnittstellenkombinationen effizient verwendet werden können.

Fazit

Verschiedene Testschnittstellen bilden die Basis einer oder mehrerer Testautomatisierungen. Auch die größten TAaaS werden nicht überleben, wenn die Testschnittstelle den gewünschten Schritt nicht ausführen kann. Hierbei handelt es sich nicht um ein neues Problem, denn es besteht schon seit den Anfangstagen der Softwareentwicklung. Probleme beim Design for Testability können nicht ohne die Beteiligung der Plattform-Provider und der Anwendungsentwicklungsframeworks gelöst werden. Es wird auch interessant sein, was die Zukunft zusammen mit Codegenerierungstools mit sich bringt, wie beispielsweise GPT-3, das heute Artikel generiert, denn viele der aktuellen Testautomatisierungstasks werden ebenfalls automatisiert werden. Wird es in Zukunft noch Arbeit für Testautomatisierungsingeníeure geben? Ja, es wird viel mehr Arbeit geben, da es Unmengen generierten Softwarecode geben wird, der nach wie vor von Menschen geprüft werden muss. Der Fokus wird sich lediglich von Testfallautomatisierung in Richtung Softwareautonomation verschieben – „Automatisierung mit einer menschlichen Note“. Design for Testability wird dann noch wichtiger sein.
 
Der Autor:

Antti Heimola ist Senior Automation Architect bei Qentinel Oy in Finnland. Er hat mehr als 25 Jahre Erfahrung in der HW/SW-Automatisierung, einschließlich mehrerer Innovationen in diesem Bereich. Er hat in verschiedenen Funktionen gearbeitet, wie HW/SW-Designer, SW-Architekt, Programm-/Produktmanager, Testmanager und in der Agile/Lean-Berater. Coaching und die Weitergabe von Wissen liegen ihm heute besonders am Herzen.

 
Diese Blogreihe wird Stories zu den Themen Testautomatisierung, W-Modell und Agile vorstellen, insbesondere aber auch Dinge, die beim Aufbau einer Testautomatisierung berücksichtigt werden müssen – vom Ein-Mann-Betrieb bis zum tausendfachen Service wie bei dem Produkt https://qentinel.com/ Pace, das ich als Beispiel für die Themen Scripting-Techniken für Testautomatisierung und Test Automation as a Service verwende.