Testautomatisierung

Die dunkle Seite der UI Test-Automation

Meine ersten Gehversuche im Bereich der UI Test-Automation waren recht holprig und frustrierend. Heute, also fast sieben Jahre später, muss ich grinsend an die vergangenen Jahre zurückdenken. Ich möchte das zum Anlass nehmen, um über meine Erfahrungen zu schreiben. Es soll kein typischer „Top 5“ oder „Top 10“ Artikel mit Gründen für eine gut durchdachte Test-Automation sein, oder gar ein Artikel der sich wie ein „hätte ich, dass früher einmal gewusst“ liest. Stattdessen möchte ich ein wenig aus dem Nähkästchen plaudern und darüber schreiben, in welchen Situationen ich mich schon befunden habe und Möglichkeiten aufzeigen, um mit diesen Situationen umzugehen. Die Liste ist bei weitem nicht vollständig. Vermutlich könnte ich noch einen zweiten und dritten Teil schreiben, aber beginnen wir einmal mit dem Ersten.

Die dunkle Seite des UI Test_Titelbild

Meine Karriere als Test-Automatisierer hat vermutlich ähnlich wie bei den meisten begonnen. Ich habe nach meiner Ausbildung (eine IT-Informatik Lehre) in einer Firma mit einer gut etablierten Quality Management Abteilung als QA-Engineer angefangen. 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, ohne etwas über Selektoren, Keywords, Data-Driven-Testing (DDT) zu wissen – ganz zu schweigen von Konzepten wie der Test-Pyramide. Vor dem Hintergrund habe ich also begonnen, bestehende Regressionstests, die zu diesem Zeitpunkt manuell kurz vor einem Big Bang Release durchgeführt wurden, zu automatisieren.

 

Fehlende Architektur

 

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.
  • Ich verwendete keine Keywords oder Data-Driven-Testing.
  • Selektoren waren dank Ranorex in einem Repository gespeichert, jedoch war die Lösung alles andere als optimal.
  • Der 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.

Eine Woche nachdem die Test-Automationslösung deployed war, holte mich die Realität ein. Die erste Änderung an der UI ließen 15 Tests mit False-Positive Ergebnissen fehlschlagen. Dank meines schlechten Codedesigns (falls man in diesem Fall überhaupt von Design sprechen kann) mussten die Tests nun alle einzeln angepasst werden. Natürlich blieb das nicht die einzige Änderung. Neue Änderungen lösten mehr False-Positives aus und ich musste noch mehr Tests fixen. Bald war ich nur noch mit dem Beheben von False-Positives beschäftigt und hatte keine Zeit mehr um 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 „ja 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 könnte 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 persönlichen Weiterentwicklung gearbeitet werden muss. Ein erfahrener Entwickler oder Test-Automation Engineer muss daher:

  • regelmäßige Codereviews durchführen.
  • mit dem Praktikanten oder Junior Pair Programming betreiben.
  • als Mentor zur Verfügung stehen (im besten Fall sogar ein 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. Und über diese Möglichkeiten sollte auch offen kommuniziert werden, und diese Weiterentwicklungsmaßnahmen in den Jahreszielen verankert werden.

 

Test-Automation geht nebenbei. Tests haben schlechtes Design

 

Die Situation:

Über die Jahre habe ich immer wieder beobachtet, dass die Test-Automation 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-Automation Engineer nicht neben täglicher Entwicklungstasks erledigt werden. UI Test-Automation 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
  • Anpassung der Testfälle aufgrund von Umstellungen in der UI
  • Implementierung neuer Tests

Die Punkte werden sehr schnell zu einer tagfüllenden Aufgabe und erst dann fängt das eigentliche Qualitätsmanagement an.
Es müssen:

  • Akzeptanzkriterien in User Stories analysiert werden.
  • basierend auf dem Analyseergebnis, Testfälle entworfen werden.
  • bestehende manuelle Regressionstests für die Test-Automation sinnvoll angepasst und implementiert 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, dennoch verlangt auch niemand von einem QA-Engineer (egal mit welchem technischen Hintergrund) ein Feature zu implementieren. Und falls doch kann nicht erwartet werden, dass die Implementierung so gut ist, wie die eines Entwicklers.

 

Wie könnte 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-Automation Engineer, ein gutes Verständnis für QM/QA im Software Lifecycle hat. Mit Schulungen wie dem ISTQB Certified Tester Foundation Level, ISQI-Certified Agile Tester oder 360° Testautomatisierung ist es möglich eine erfolgreiche Entwicklung zum Test-Automation 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.

Roboter_keep calm i will fix it

Save the Environment

Die initiale Idee zu diesem Artikel ist mir an einem Freitag nach einer sehr anstrengenden frustrierenden Woche gekommen. Ich war zu diesem Zeitpunkt circa 4 Monate in einem Kundenprojekt. Das Refactoring der bestehenden Solution war abgeschlossen (soweit beim Refactoring jemals von einem Abschluss gesprochen werden kann). Die angeforderten Regressionstests waren implementiert und ich hatte Anforderungsmeetings mit den verantwortlichen Product Ownern. Neue Features wurden zu diesem Zeitpunkt mit circa einem halben Sprint Versetzung vom Test-Automation Framework getestet.

 

Die Situation:

Wie jeden Morgen überprüfte ich auch am Montagmorgen besagter Woche meine Testreports.

100% der Tests sind fehlgeschlagen.

Noch nicht weiter schlimm, ich wusste, dass Sonntagabend beim Kunden Batches remote eingespielt und Systeme neu gestartet werden. Dadurch müssen die Nodes des Selenium Grids manuell gestartet werden. Es gibt Tasks, die beim Hochfahren des Systems der Clients die Nodes starten sollte, aber wer weiß was da schon alles schiefgegangen sein mag. Nachdem das Test Environment bereit war konnten die entsprechenden Jenkins Jobs getriggered werden. Eine kurze Frühstückspause später musste ich feststellen, dass alle Tests erneut fehlgeschlagen waren. Ich überprüfte das Test-Automation Framework lokal auf meiner Workstation und es funktionierte alles.

In den nächsten Absätzen werde ich das „aber“, welches an dieser Stelle natürlich folgen muss, genauer ausführen. Dafür werde ich in die technischen Details des Settings hineinzoomen. Leser, die mit Selenium und dem Test von Webapplikationen nicht gut vertraut sind, mögen mir diesen technischen Exkurs verzeihen und beim „Fazit der Situation“ weiterlesen.

Bis ich herausgefunden hatte, dass es auf zwei von drei Nodes automatische Chrome Updates gegeben hat, war ein ganzer Vormittag vergangen. Es dauerte einen halben Nachmittag herauszufinden, dass es einen Bug im verwendeten Selenium ChromeDriver gab, der mit den neuen Sicherheitseinstellungen von Chrome nicht umgehen konnte.

Der Bugfix von Selenium/Chromedriver wurde am Mittwoch darauf veröffentlich und hätte funktionieren sollen. Hätte … hat er aber nicht.

Es hat mich einen ganzen Tag gekostet herauszufinden, dass der Kunde, Chrome Extensions auf eine Whitelist setzt und ChromeDriver bei Start einer neuen Chrome Instanz eine neue Automatisierungsextension entpackt und diese installiert.
Dabei handelt es sich, wie soll es anders sein, um keine offizielle Extension aus dem Chrome Web Store. Der Kunde kann aus Sicherheitsgründen diese Extension nicht auf die Whitelist setzen, und so musste die Extension manuell in die Registry eingetragen werden.

Der Montag an sich, oder eigentlich die gesamte Woche wäre nicht weiter schlimm gewesen. Die Test-Automation läuft auf mehr als nur einen Browser. In diesem Fall Firefox.

Ganz nach dem Motto, ein Bug kommt selten allein, haben die Firefox Test am Montag ebenfalls nicht funktioniert (gemerkt habe ich dieses erst am Dienstag, da ich am Montag mit Chrome ausgelastet war). Auch hier gab es ein automatisches Update. Diesmal waren es keine Extensions, die Probleme machten, sondern die Zertifikatsverwaltung.

Kurze Erklärung: Im Kundenumfeld wird ein Enterprise Root Zertifikat benötigt um mit dem Browser aus dem internen Netzwerk zu kommen, das Zertifikat ist in der Windows Zertifikatverwaltung hinterlegt. Firefox verwaltet seine Zertifikate eigens und greift nicht auf die Windows Zertifikatsverwaltung zu. Dadurch muss in jedes Profil das Enterprise Root Zertifikat manuell eingespielt werden. Jede vom Geckodriver gestartete Instanz, legt ein neues Firefox Profile an. Der Geckodriver hat eine Funktion, die es ermöglicht das Zertifikat mitzugeben, aber nicht in einem Selenium Grid Environment. Da gab es zu dem Zeitpunkt einen Bug.

Fazit der Situation: Durch die Komplexität des Environments und der Menge an Abteilungen mit denen ich sprechen musste um alle Informationen zu erlangen, die ich benötigte um die Probleme erst zu erkennen und dann zu lösen, war die Test-Automation eine knappe Woche komplett lahmgelegt.

 

Wie könnte mit der Situation umgegangen werden?

DON’T PANIC

Komplexe Umgebungen mit noch komplexeren Rollen- und Rechtesystemen, die historisch gewachsen sind, sowie lieblos geklonte Testumgebungen, die meist mit viel zu wenig Speicher virtualisiert sind, kommen leider sehr häufig vor. Es kommt immer wieder zu Daten oder auch Versionsunterschieden zwischen Test-, Staging- und Produktionsumgebung, die nicht beeinflusst werden können.

Ich nenne das die äußeren Einflüsse. Selbst wenn die Test-Automation vermeintlich richtig aufgesetzt ist, manche Dinge liegen außer unserer Kontrolle.

In diesen Fällen kann meiner Meinung nach nichts anders gemacht werden, als mit den entsprechenden Personen zu reden, regelmäßig auf bestehende Probleme hinzuweisen und Ruhe bewahren. Es wird sich irgendeine Lösung finden.

Ideal für den Umgang mit solchen Problemstellungen sind Organisationen, die sich mit DevOps auseinandersetzen und die die damit verbundenen Prinzipien ernst nehmen und auch leben.

 

Fazit – Testautomatisierung ist hoch-spezialisierte Softwareentwicklung!

Es gibt viel zu tun. Jeder braucht oder will UI Test-Automation. Die Wenigsten sind sich allerdings bewusst was das wirklich bedeutet.
Heute mehr denn je entwickelt sich UI Test-Automation zu einer eigenen Disziplin in der Softwareentwicklung. Und es ist genau das: hochspezialisierte Software-Entwicklung. Es ist wichtig, jungen Einsteigern und „alten Hasen“ die richtigen Werkzeuge zu geben, mit denen sie ihr Team unterstützen und das Projekt zu einem Erfolg machen können.

 

Passende Artikel

Antwort schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*