Ich blicke zurück auf ein Beratungsprojekt im Testumfeld. Damals herrschte eine äußerst angespannte Situation, da durch die weitestgehend manuellen Test der Ressourcen- und Zeitaufwand für das Testen zu groß war. Um das Projekt in überschaubarer Zeit mit eingeschränkter Zielsetzung wieder beruhigen zu können, beschloss der Kunde, den Zauberstab „Testautomatisierung“ zu schwingen.
Man erwartete von mir, als externem Testautomatisierungsexperten, dass ich diese Gelegenheit sofort nutzen und ohne Zögern mit der Automatisierung der manuellen Tests beginnen würde. Zu diesem Zeitpunkt war die Testautomatisierung bereits nach einer von mir durchgeführten Machbarkeitsstudie operativ einsatzbereit, und ich war mir ihres Potenzials bewusst. In der Präsentation der Testautomatisierungslösung konnten zentrale Problemstellungen des Projekts erfolgreich angesprochen werden. Dieser offensichtliche Erfolg führte bei einigen Entscheidern nahezu zwangsläufig zu der Überzeugung, dass es ab jetzt nur noch bergauf gehen könne.
Zwischen Wunschdenken und Realität
In den anschließenden Diskussionen war es mitunter schwierig, Wunschdenken von der Realität zu unterscheiden. Die wichtigsten Erkenntnisse ähneln stark einem Auszug aus dem aktuellen Lehrplan des ISTQB-Seminars für Testautomatisierungsentwickler/-ingenieure (CT-TAE) zum Thema Erwartungshaltung:
- Nicht alles kann direkt beobachtet werden: In einer strukturierten Testautomatisierungsentwicklung sollten stets klar formulierte Anforderungen umgesetzt werden, analog zur "produktiven" Softwareentwicklung. Allerdings ist nicht immer alles sofort erkennbar und prüfbar. Häufiger als erwartet stellte sich heraus, dass qualitative Aspekte der zu testenden Software durch Testautomatisierung nur begrenzt effizient überprüft werden konnten. Funktionale Eigenschaften sind wesentlich einfacher zu handhaben als qualitative. Die Testautomatisierung muss daher sorgfältig auf der Grundlage der Anforderungen gesteuert werden.
- Die Testautomatisierung kann doch nicht so kompliziert sein, wenn das Testobjekt aus Endbenutzersicht gut bedienbar gestaltet und äußerlich einfach wirkt: In den meisten Fällen, in denen ich diese Aussage gehört habe, war das Gegenteil der Fall! Die versteckte Komplexität scheinbar einfacher Lösungen kann den Aufwand für die Erstellung einer effektiven Testautomatisierung erheblich erhöhen. Auch hier gilt der Grundsatz: Nur durch eine gründliche Analyse lässt sich eine fundierte Aussage zur Komplexität und zum Aufwand der Testautomatisierung treffen. Alles andere ist ein riskantes Unterfangen mit ungewissem Ausgang.
- Es kann nichts Schlimmes mehr passieren, wenn die Testautomatisierung sich auf die Anwendersicht konzentriert und die Fehler auf dieser Ebene gefunden werden: Mit dieser Argumentation wird häufig der umfassende Systemtest aus Sicht des Endbenutzers in den Mittelpunkt gerückt – auch als End-to-End-Test bekannt. Dabei wird gerne übersehen, dass dies die aufwändigste, eingeschränkteste und anfälligste Ebene der Testautomatisierung ist. Die Testpyramide verdeutlicht, dass wir mit diesem Ansatz nur einen geringen Teil der möglichen Fehlerzustände abdecken können. Endanwender:innen können auf der Benutzeroberfläche bestimmte Teile des Systems möglicherweise nicht auf potenzielle Fehler prüfen, da verschiedene Ebenen und Bereiche der Software von dort aus nicht zugänglich sind. Zudem ist diese Testebene äußerst anfällig für Änderungen im System. Jede kleine Änderung kann die Basis für Tests und Fehlerzustände neu definieren und führt oft zu neuen Fehlern, die mit den bestehenden Tests nicht entdeckt werden können.
- Wenn wir die Oberfläche der Software optisch identisch mit neuer Technologie aufbauen, sollte die Testautomatisierung das doch locker wegstecken können und weiterhin funktionieren: Diese Erwartungshaltung war für mich ein Höhepunkt im laufenden Projekt! Die Erfahrung zeigt, dass bei einer oberflächenbasierten Testautomatisierung technische Änderungen an der Endbenutzerschnittstelle meist erhebliche Auswirkungen haben. Um die visuell gleichartige Oberfläche der Software mit einer anderen Technologie neu zu erstellen, benötigte die Entwicklung beinahe das Dreifache des ursprünglich geschätzten Aufwands. Warum sollte diese Umstellung in der Testautomatisierung dann einen vernachlässigbar kleinen Aufwand erfordern? Die endgültigen technischen Eckdaten standen uns erst kurz vor Abschluss der Umsetzung zur Verfügung. Trotzdem mussten wir aufgrund der gleichzeitigen Weiterentwicklung der Funktionalität kontinuierlich Tests durchführen – mit allen daraus resultierenden Nachteilen. Daher flossen viele zuvor nicht eingeplante Stunden in die Wartung der Testautomatisierung.
Jeder dieser Aspekte stellte die Testautomatisierer:innen vor Herausforderungen, die es zu lösen galt. Dies gelang nicht bei allen Problempunkten optimal, das Gesamtbild aber passte durchgehend recht gut.
Ein wesentlicher Erfolgsfaktor war die frühzeitige systematische Analyse und Bewertung der Anforderungen an die Testautomatisierung sowie die kontinuierliche transparente Darstellung der Grenzen der Testautomatisierung.
