Testautomatisierung – so gehts

Erfolgsfaktor Testautomatisierung (Teil 2)

Nach fast zwei Jahrzehnten Erfahrung im Bereich Test- und Qualitätsmanagement und die damit einhergehende Bewältigung von Herausforderungen, lies mich im ersten Teil die aus meiner Sicht massgeblichen Erfolgsfaktoren unserer heutigen Zeit skizzieren. Sicherlich waren die aufgeführten Punkte subjektiver Natur. Bestätigt wird dies allerdings durch das allseitige Bestreben, agile Prozesse und CI/CD als Service-Leistung in den Unternehmen zu etablieren. Ziel ist hierbei schnellstmöglich Anforderungen zu realisieren und ebenso schnelle eine gesicherte und belastbare Qualitätsaussage zu erhalten.

Mit dem Bestreben effizientere Prozesse und Services für die Entwicklung von Software zu etablieren ändert nichts an der Tatsache, dass aus Sicht Test-Management stets zwei Säulen als Basis der aktiven Qualitätssicherung herangezogen werden:

  1. Regression Testing: Die bestehende Implementierung muss immer noch den aktuell gültigen Anforderungen entsprechen.
  2. Progression Testing: Neue Features des aktuellen Sprints müssen wie gefordert umgesetzt worden sein.

Die Erfahrung hat gezeigt, dass gegen Ende der Entwicklungsphase nicht immer genügend Zeit für die Durchführung aller geplanter Tests vorhanden ist. Dabei spielt es keine Rolle, ob man sich in einem agilen Projekt mit einem kontinuierlichen Testansatz befindet, oder ein klassisches Projekt mit Wasserfall-Approach unterstützt. Zeit ist immer ein Killer-Faktor und das Testing muss oft die Verzögerungen der Entwicklung durch Nachtschichten oder Wochenendarbeit kompensieren. An dieser Stelle soll erwähnt sein, dass die Einführung von Risk-based Testing als Strategie zur Effizienzsteigerung bei der Priorisierung und Ausführung der Testfälle an immer stärkerer Bedeutung gewinnt. Dies wird ein eigener Beitrag sein.

Die Qualitätssicherung kann das Testobjekt nicht gesund testen, aber durch geeignete Massnahmen aufzeigen wo die Lücken zwischen Realisierung und Anforderungen bestehen. Die Umsetzung sollte in dem hier vorgestellten Continuous Test Automation (CTA) Approach vorgestellt werden. CTA konzentriert sich primär auf zwei Ziele:

  1. Die frühestmögliche Aufdeckung von Abweichungen gegenüber den Anforderungen
  2. Kontinuierliches Q-Feedback an das Team und seine Stakeholder

Die frühestmögliche Aufdeckung von Abweichungen schlägt folgende beiden Massnahmen zur kontinuierlichen Qualitätsverbesserung vor:

  • Aus Whitebox-Sicht wird die konsequente Einführung des Test Driven Development (TDD) seitens der Entwicklung empfohlen. Das setzt Disziplin seitens der Entwickler voraus, garantiert aber im Gegenzug für alle Beteiligten nachvollziehbare und somit verifizierbare Ergebnisse. Die Entwicklung und Administration von Unit-Tests wird von den meisten Entwicklungsumgebungen heute standardmässig unterstützt.
  • Aus Blackbox-Sicht gestaltet sich die Verifikation des Produktinkrements etwas anspruchsvoller, da man ab einer gewissen Komplexität, verbunden mit dem Anspruch der Nachvollziehbarkeit und Transparenz, sowie dem permanenten Mangel an Zeit, um eine Testautomatisierung nicht herum kommen wird.

Testautomatisierung

Die Automatisierung von Testfällen setzt voraus, dass diese in einer adäquaten Umgebung ausführbar sind und das Produktinkrement ein gewisses Mass an Invarianz aufweist. Ist dies der Fall, können mittels geeigneter Capture/Replay-Tools in einer ersten Iteration relativ schnell reproduzierbare Ergebnisse erzielt werden. In diesem Schritt sollte es nicht primär um die Wiederverwendbarkeit von einzelnen Testschritten gehen, sondern vielmehr um die Frage, ob die im Fokus stehenden Business-Szenarien von den Anforderungen abweisen. Die aufgezeichneten Testszenarien sollten jederzeit eine erneute Verifikation erlauben. Erst in zweiter Linie, verbunden mit einem gewissen Reifegrad, sollte das Refactoring der Tests stattfinden. Findet dies zu früh statt, würde diese Aufgabe in Detailbetrachtungen enden, ohne für die Stakeholder einen ersichtlichen Nutzen zu haben. An dieser Stelle sei gesagt, dass Testautomatisierung letztendlich auch ein eigenständiges Entwicklungsprojekt ist, dass iterativ und inkrementell vorangetrieben werden muss, um den eigenen Qualitätszielen zu genügen.

Das zweite Ziel “Kontinuierliches Q-Feedback” wird durch die wiederkehrende Ausführung zuvor implementierter Test-Skripte in Form von Testsets etabliert. Diese können manuell oder automatisiert via Scheduler ausgeführt werden. Wichtig ist hierbei, dass sich das Team auf ein sinnvolles und abgestimmtesVorgehen einigt. Hier einige Beispiele:

  • Erst wenn alle Unit-Tests “passed” sind, werden die automatisierten User-Tests durchgeführt. Hiermit wird sichergestellt, dass das Entwicklungsteam ein gewisses Mass an Grundqualität liefert und nicht Features einfach über den Zaun wirft, um getestet zu werden.
  • Jeden Morgen wird ein Early Morning Check ausgeführt, der verifiziert, ob die integrierten Schnittstellen des Lieferanten immer noch zur Verfügung stehen. Während der Testdurchführungsphase nimmt das den möglichen Frust aus dem Testteam und die Business-Abnahme kann sich neu organisieren, wenn die notwendigen Schnittstellen nicht zur Verfügung stehen.
  • Die Bereitstellung einer virtuellen Maschine, zum Beispiel einer Data Warehouse Umgebung mit ihren Daten und Schnittstellen, wird erst durch die automatisierte Abarbeitung von Prüfpunkten und anhand ihres Ergebnisses für die Anwender freigegeben. Dies reduziert das Risiko, von der zeitlichen Verfügbarkeit eines Prüfers anhängig zu sein.

All diese Massnahme und Ansätze schaffe ein Höchstmass an Transparenz und geben zugleich eine gute Grundlage für durchzuführende Sprint Retrospektiven.

Erfolgsfaktor Testautomatisierung

Fazit

Jede Idee ist nur so gut, wie die Akzeptanz und Qualität ihrer Umsetzung. Hinzu kommt die notwendige Einsicht, dass der zuvor betriebene Aufwand der Testautomatisierung sich mittel- bis langfristig rechnen wird. Die Vorteile einer CTA (Continuous Test Automation) sind vielfältig und fangen bei der Verfügbarkeit und Transparenz der Testergebnisse an, gehen weiter zu einer Objektivierung und Personenunabhängigkeit und könnten dann sogar in einem Managed Service mit entsprechender Kostenkontrolle ausgelagert werden.

Autor

Harald Schmidt (t), Quality Professional, Testmanager

Leider hat Harald diese Welt viel zu früh verlassen. Seine Beiträge und vor allem seine Menschlichkeit und gute Laune werden uns immer in Erinnerung bleiben.

Dein Kontakt

Maarten de Ruiter, Quality & Development Professional

Maarten ist Engineer durch und durch. Als Entwickler mit Schwerpunkt Testautomatisierung beschäftigt er sich mit dem Entwickeln und Implementieren von Testsystemen und zielorientierten Automatisierungslösungen. Neben neuer Technik ist für ihn das Alte ebenso faszinierend: In seiner Freizeit schraubt er gerne an Oldtimern herum.