Die dunkle Seite der UI Test-Automation – Teil 1

Meine ersten Gehversuche im Bereich der UI-Testautomatisierung waren recht holprig und frustrierend. Heute, fast neun Jahre später und um viele Erfahrungen in der automatisierten Qualitätssicherung reicher, muss ich schmunzeln, wenn ich an meine Anfänge zurückdenke. Ich kann mich glücklich schätzen, denn ich hatte gute Mentoren, die mich mit Wissen und genug Motivation versorgt haben, um danach zu streben ein besserer Entwickler zu werden.

Auf meiner Reise habe ich viele Bücher und noch mehr Artikel gelesen - über "Best Practices" rund um Architektur von Testautomatisierung, Softwareentwicklung und alles, was mit Entwicklung im Allgemeinen zu tun hat. Aber irgendwie habe ich nur selten über Probleme oder unangenehme Situationen in der UI-Testautomatisierung gelesen. Doch die gibt es definitiv! Es fehlte mir zu erfahren, wo man etwas falsch machen könnte und was man im Team oder gar auf Organisationsebene tun oder nicht tun sollte.

Dieser zweiteilige Artikel ist keine "Top 5" oder "Top 10" Sammlung, wo ich aufliste, was auf technischer Ebene zu vermeiden oder zu tun ist. Vielmehr ist es meine ehrliche Einschätzung der wirklichen Probleme in der (UI-)Testautomatisierung.

Meine Karriere als Test-Automatisierer begann aufgrund schlechter Kommunikation. Um ein wenig Hintergrund zu geben: Ich bin ein Quereinsteiger und habe, bevor ich in der IT begann, als Koch gearbeitet. Ich hatte eine recht grundlegende Ausbildung (eine IT-Informatik Lehre), die es mir ermöglichte, in der IT-Welt Fuß zu fassen. Mein Praktikum, das ich im Zuge meiner Lehre absolvieren musste, begann recht vielversprechend. Ich musste ein kleines Tool schreiben, das es ermöglicht, Daten von einem Testmanagementtool in ein anderes Tool automatisch zu übertragen.

Die Firma war mit meiner Performance sehr zufrieden und hat mir einen Job angeboten. Da ich ein paar Coding Skills in C# hatte, hat mein Chef mir eines Tages verkündet, dass wir mit einem Tool UI Test-Automation implementieren werden. Ich bekam Ranorex vorgesetzt, ein Record&Play Tool mit der Möglichkeit, Testfälle in C# zu schreiben.

Ok, mein neues Projekt war es also, Test-Automatisierung zu schreiben. Alleine. Ohne Senior Entwickler oder einem zweiten Junior, mit dem ich mich gegebenenfalls hätte austauschen können.

Ich wusste zu dem Zeitpunkt nichts über Test-Automatisierung oder dass es so etwas überhaupt gibt. Ich wusste nichts über Konzepte wie Data-Driven-Testing (DDT), oder Keyword-Driven-Testing, hatte im Grunde genommen kein Verständnis dafür Code zu strukturieren oder wiederverwendbar zu schreiben. Natürlich habe ich noch nie etwas von der Test-Pyramide oder Xpath-Selektoren gehört.

Um es einfach zu halten, ich war ein totaler Noob.

Meine Anforderung war, dass ich die bestehenden Regression Tests, die manuell durchgeführt werden, nehme und sie automatisiere. Habe ich erwähnt, dass ich keine Ahnung hatte, dass man manuelle Tests nicht 1:1 nehmen kann, um sie zu automatisieren? Gut, ich wusste nicht mal dass es sowas wie Test-Design gibt. 

Problem 1: Fehlende Architektur, fehlende Coding Skills, fehlendes „Alles“

Die Situation:
Als ich angefangen habe, wusste ich nichts von Clean Code, den SOLID Prinzipien oder wie Code strukturiert werden sollte. Wie nicht anders zu erwarten, war die erste Test-Automation Lösung ein schlimmer Fall von Spaghetti Code.

• Ein Testfall war eine Methode, was ok klingt, weil heute mache ich es nicht anders. Aber es war nicht ok, weil die komplette Logik und die komplette Kommunikation mit dem SUT über diese Methode implementiert wurde.
• Ich verwendete keine Keywords und auch kein Data-Driven-Testing.
• Selektoren waren dank Ranorex in einem Repository gespeichert, jedoch war die Lösung alles andere als optimal.
• Der Source Code hatte unendlich viele Duplikationen.

Trotz des schlechten Designs hat die Test-Automation zunächst so funktioniert wie ich mir das beim „Programmieren“ vorgestellt hatte. Daher war ich zufrieden und sah keinen Bedarf, irgendetwas daran zu ändern.

Nicht mal drei Nightly runs nachdem die Test-Automationslösung deployed war, holte mich die Realität ein: Die erste Änderung an der UI ließen 15 Tests fehlschlagen. Dank meines schlechten Codedesigns (falls man in diesem Fall überhaupt von Design sprechen kann) mussten ich die Tests alle einzeln anpassen. Natürlich blieb das nicht die einzige Änderung. Neue Änderungen lösten mehr Fehlschläge aus und ich musste noch mehr Tests aber auch schon gefixte Test fixen. Bald war ich nur noch mit dem Beheben von False-Positives beschäftigt und hatte keine Zeit mehr neue Tests zu implementieren.

Ich habe schon öfters miterleben müssen, dass Testframeworks von erfahrenen Senior Entwicklern mit guten Ansätzen aufgesetzt wurden, die dann leider in Vergessenheit geraten sind. Irgendwann wurden die Frameworks dann von einem Praktikanten übernommen, weil UI Test-Automation PLÖTZLICH „notwendig wäre“. Das Ergebnis ist meist dasselbe: die Test-Automation ist nicht effizient, bekommt einen schlechten Ruf und wird bald darauf nicht mehr verwendet.

Wie kann mit der Situation umgegangen werden?

Ein Test-Automation Engineer hat meiner Meinung nach eine Hybridrolle. Einerseits ist er ein QA-Engineer, andererseits ist er ein Entwickler. Das heißt, ein Test-Automation Engineer soll ein Verständnis für Testdatenmanagement und Testdesign haben, sowie programmieren und ein wartbares Framework implementieren können, und ein solches in weiterer Folge auch erweitern. Es spricht nichts dagegen einen Praktikanten oder einen Junior als Test-Automation Engineer auszubilden. Ich begrüße diese Herangehensweise, jedoch sollte man nicht vergessen, dass wie bei jedem Junior intensiv an der fachlichen, sowie auch an der persönlichen Weiterentwicklung gearbeitet werden muss. Ein erfahrener Entwickler oder Test-Automation Engineer muss daher:

• regelmäßige Codereviews durchführen,
• Pair Programming Sessions organisieren,
• als Mentor zur Verfügung stehen (im besten Fall sogar ein Trainings-Programm bereitstellen),
• realistische, messbare Ziele vorgeben und auch nachverfolgen.

Für jemanden, der mit Test-Automation beginnt, bedeutet das, dass derjenige sich mit Literatur wie z.B. Basiswissen Testautomatisierung oder einschlägigen Blogs im Selbststudium weiterbilden sollte. Es sollte die Möglichkeit geben, an Schulungen und Konferenzen teilzunehmen, welche Themen wie SW-Entwicklung, Testing und Test-Automation behandeln. Diese Möglichkeiten sollte auch offen kommuniziert werden, und diese Weiterentwicklungsmaßnahmen in den Jahreszielen messbar und transparent verankert werden.

Problem 2: Test Automatisierung geht nebenbei

Die Situation:
Über die Jahre habe ich immer wieder beobachtet, dass die Test Automatisierung von einem Entwickler aufgesetzt und weiterentwickelt werden soll. Der Grundgedanke, einen Entwickler entwickeln zu lassen, spricht für die Vorgehensweise, jedoch kann die Arbeit des Test Automatisierung Engineer nicht neben täglicher Entwicklungstasks erledigt werden. UI Test Automatisierung wird mit der Zeit immer umfangreicher, sodass es keine Nebenaufgabe bleiben kann. Typische Tagesaufgaben sind:

• Auswertung fehlgeschlagener Tests
• Reproduzieren der aufgedeckten Fehler
   - Erstellung von Bug Tickets
   - Oder Selektoren anpassen
• Anpassung der Testfälle aufgrund von Umstellungen in der UI
• Implementierung neuer Tests
• Testdatenmanagement (Aufbereiten, Anonymisieren oder Synthetisieren von Daten)
• Management der Testumgebung
• In manchen Fällen muss sich die TA auch um die Service-Virtualisierung kümmern

Die Punkte sind nötig, um ein robustes und wertvolles Framework zu gewährleisten, mit dessen Ergebnissen eine hochwertige Aussage über die Qualität des SUT getroffen werden kann. All das wird schnell zur tagesfüllenden Aufgabe und erst dann beginnt die Arbeit im Bereich des Qualitätsmanagements. Aufgaben die zu erledigen sind:

• Akzeptanzkriterien in User Stories müssen analysiert werden.
• Basierend auf dem Analyseergebnis, müssen Testfälle designed werden.
• Bestehende manuelle Regressionstests müssen für die Test Automatisierung sinnvoll angepasst und implementiert werden.
• Tests sollten dokumentiert werden und im besten Fall mit der jeweiligen Userstory oder Akzeptanzkriterium Stories gemappt werden.

Aufgrund von Ausbildung und Erfahrungswerten haben Entwickler und QA-Mitarbeiter unterschiedliche Blickpunkte auf Softwarequalität. Diese Tatsache kann sich auf das Testfalldesign auswirken. Ich will damit nicht sagen, dass Entwickler nicht testen können, oder Testfälle schlechter designen, schließlich schreiben Entwickler tagtäglich Unit und Integrations-Tests - trotzdem ist der Fokus dabei ein ganz anderer als bei UI Tests. Man sollte beide Sichten in einem Team wertschätzen und diese zu seinem Vorteil nutzen.

Wie kann mit der Situation umgegangen werden?

Test-Automation geht nicht nebenbei!

Wird ein Entwickler für die UI Test-Automation eingesetzt, muss gewährleistet sein, dass diese auch Vollzeit entwickelt werden kann. Wenn einmal Zeit bleibt, kann an Entwicklungstasks gearbeitet werden, aber der primäre Fokus muss bei der Test-Automation liegen.

Meiner Meinung nach ist es wichtig, dass ein Test Automatisierungs Engineer ein gutes Verständnis für QM/QA im Software Lifecycle hat. Mit dem ISTQB Kursprogramm und weiteren Trainings, ist es möglich eine erfolgreiche Entwicklung zum Test Automatisierungs Engineer zu fördern. Zusätzlich sind Reviews von implementierten Testfällen mit Fokus auf Testdesign durch erfahrene QA-Engineers sehr wertvoll und helfen dabei schlechtes Testdesign zu minimieren. Das hat sich übrigens auch als gute Praxis erwiesen Unit Tests mit QA-Engineers zu reviewen um eine bessere Testabdeckung zu bekommen.

Fazit

Damit möchte ich den ersten Teil dieser Serie beenden, auch wenn es noch viel mehr gibt, was bei der Test Automatisierung schief gehen kann. Mein Punkt ist: Testautomatisierung ist Softwareentwicklung. Dementsprechend muss es behandelt werden. Es sollte als Projekt in einem Projekt behandelt werden.  Erst wenn jeder an Bord ist und die Wichtigkeit versteht, erst dann kann Test Automation den Mehrwert ins Team bringen der sich dadurch versprochen wird.

>> "Die dunkle Seite der UI Test-Automation - Teil 2"