So aktivieren Sie Wiederverwendbarkeit mit Objekt-Repositories im Automatisierungstest
Empfinden wir als Automatisierungsentwickler:innen nicht eine gewisse Zufriedenheit, wenn wir vom manuellen Testteam oder dem Kunden hören, welchen Nutzen sie aus unserer entwickelten Automatisierung gezogen haben? Für diesen Erfolg setzen wir auf eine hochwertige Automatisierungssuite, die nicht nur robust, sondern auch leicht an neue technische oder geschäftliche Anforderungen anpassbar ist. Die Wartung muss einfach sein – erinnern wir uns immer wieder. Wie lässt sich dies erreichen?
Neben mehreren Möglichkeiten, die hohe Qualität einer Testautomatisierungssuite zu gewährleisten, gehört dazu auch die Wiederverwendbarkeit – nicht nur durch die Wiederverwendung häufig genutzter Testschritte, sondern auch von häufig verwendeten UI-Objekten. In diesem Beitrag erkläre ich, wie wir Objekt-Repositories nutzen können, um den Aspekt der Wiederverwendbarkeit durch die erneute Nutzung von Objekten in einem UI-Testautomatisierungsprojekt zu verbessern.
- Was ist ein Objekt-Repository im Bereich der Automatisierungstests?
- Warum ist es wichtig?
- Best Practices beim Einsatz von Objekt-Repositories
- Wie erstellt man Objekt-Repositories (Beispiele)
Was ist ein Objekt-Repository im Bereich der Automatisierungstests?
Wenn Sie beginnen, eine Testautomatisierungssuite zu entwerfen, stellen die meisten von uns sicher, dass Codeblöcke nicht erneut geschrieben werden. Dafür entwickeln wir wiederverwendbare Funktionen und stellen gemeinsam nutzbare Codeblöcke in Bibliotheken bereit. Aber: Haben Sie schon einmal häufig verwendete UI-Objekte wiederverwendet? Falls nicht, erkläre ich Ihnen, wie Sie dies mit einem Objekt-Repository als Basis tun können.
Ein Objekt-Repository ist eine Sammlung von UI-Objekten, die üblicherweise zusammen verwendet werden. Dies fördert nicht nur die Wiederverwendbarkeit, sondern sichert auch Zuverlässigkeit und einfaches Management der UI-Elemente in der Automatisierungssuite.
Beim Erstellen der Testautomatisierungsskripte haben Sie die Testschritte mit jedem dieser UI-Objekte verknüpft. Zum Beispiel durch –
- Eingabe in ein Textfeld-UI-Objekt
- Auslesen des Texts eines Label-UI-Objekts
- Klicken auf das Hyperlink-Objekt … und so weiter.
Wie steigern Sie nun die Wiederverwendbarkeit durch die erneute Verwendung der UI-Objekte, mit denen Ihre Skripte arbeiten?
Ganz einfach, falls Ihr eingesetztes Testautomatisierungstool über ein „Objekt-Repository“ verfügt. Über ein Objekt-Repository können Sie UI-Objekte strukturiert sammeln, hinzufügen, löschen, verwalten oder aktualisieren. Sie können diese Objekte dann durch Referenzierung wiederverwenden.
Betrachten wir eine Situation, in der Sie kein OR in Ihrer Testautomatisierungssuite verwendet haben. In diesem Fall müssen Sie für verschiedene Testautomatisierungsskripte, die das gleiche UI-Widget nutzen, mehrere Kopien desselben UI-Objekts in jeden Tests auslagern, um Aktionen darauf auszuführen.
Schauen wir uns nun den Fall an, in dem Sie ein OR nutzen. Dann hätten Sie einen zentralen Ort/ein Repository, in dem Sie die UI-Objekte speichern. Jedes Testskript, das auf das gleiche UI-Objekt/Widget zugreifen muss, bezieht sich auf das im OR gespeicherte UI-Objekt. Es gibt nur eine Kopie des UI-Objekts in der Testsuite, auf das mehrere Testskripte zugreifen. Hier kommt die Wiederverwendbarkeit zum Tragen!
Warum ist es wichtig?
Meine erste Erfahrung mit der Nutzung eines OR hatte ich im IBM Rational Functional Test Automation Tool. Seitdem prüfe ich, wann immer ich ein neues Tool kennenlerne, ob dieses die OR-Funktion bietet oder nicht.
Das erste Mal habe ich ein OR eingesetzt, als unser Team eine große administrative Web-UI-Konsole mit mehreren Seiten automatisieren musste. Wir hatten über 100 Testfälle zu automatisieren. Hätten wir kein OR genutzt, wäre die Automatisierung eine große Herausforderung gewesen. Unsere Analyse ergab, dass unser Automatisierungsprojekt das perfekte Beispiel für den Einsatz eines OR war.
Warum?
1. Jeder der automatisierten Testfälle hatte mehrere gemeinsame Teilabläufe und somit gemeinsame zugehörige UI-Widgets.
Durch die gemeinsamen Teilabläufe gab es in verschiedenen Szenarien zwangsläufig gemeinsame UI-Objekte. Wir wollten nicht immer wieder dieselben UI-Objekte duplizieren und haben uns deshalb für die Wiederverwendung entschieden.
Beispielsweise musste eine Reihe von Testfällen zunächst über dieselben Navigationsmenü-Links geführt werden, bevor weitere Schritte durchgeführt werden. Daher planten wir, ein Repository nur für die Verwaltung aller Navigationslinks zu erstellen. So konnten wir die Navigationsmenü-Links in einer OR-Datei wiederverwenden.
2. Uns wurde mitgeteilt, dass es künftig zu UI-Änderungen kommen könnte – etwa bezüglich Hyperlinks, Beschriftungen etc.
Wir wollten sicherstellen, dass im Falle solcher UI-Updates die Testautomatisierungssuite Änderungen leicht übernehmen kann und der Wartungsaufwand gering bleibt.
An dieser Stelle kam das OR uns zugute: Wir mussten die UI-Objekte in jedem Testskript nicht mehrfach ändern. Wann immer es eine Änderung gab, musste lediglich das zugehörige Objekt im OR aktualisiert werden und die Testskripte liefen weiterhin mit dem aktualisierten UI-Objekt.
3. Wir mussten innerhalb eines Monats ein Testautomatisierungs-Framework mit über 100 Skripten erstellen!
Hier kam ein weiterer Vorteil der Verwendung eines OR zum Tragen: Da wir uns entschieden hatten, ein OR aufzubauen und nicht alle immer wieder dieselben UI-Objekte hinzufügen mussten, sparten wir Zeit. Wir bauten ein gut organisiertes OR auf und mussten unseren Code nur um die Objekte herum erstellen, die wir im OR organisiert hatten.
Wir konzentrierten uns auf das Ziel und die Geschäftslogik der Testfälle, anstatt Zeit damit zu vergeuden, das Rad beim Hinzufügen von Objekten für jedes Testskript neu zu erfinden. So sparten wir Zeit und lieferten die Testautomatisierungssuite schließlich innerhalb des anvisierten Monats ab!
Best Practices bei der Verwendung von Object Repositories
Jetzt, wo du Situationen kennst, in denen ein UI Object Repository hilfreich ist, willst du sicherlich wissen, worauf es ankommt, oder?
1. Erarbeitet euch als Team ein gemeinsames Ziel der Wiederverwendbarkeit. Versteht gemeinsam, warum das dem Automatisierungsteam, dem manuellen Testteam und letztlich auch dem Kunden helfen kann.
2. Bleibt beim Entwickeln der Testautomatisierungssuite als Team immer synchron und informiert euch gegenseitig über die Objekte, die ihr erstellt. Legt gemeinsame Gruppierungsregeln und Namenskonventionen fest, an die sich alle halten. Zu Beginn könntet ihr einen Plan erstellen, wie ihr jede der OR-Dateien organisieren und speichern wollt. Zum Beispiel: Navigationsmenü-Objekte in einer OR-Datei, UI-Objekte für die Login-Seite in einer anderen usw. Legt auch fest, wie die Objekte benannt werden, damit sie leicht zu finden sind.
3. Benennt die UI-Objekte so, dass sie lesbar, leicht auffindbar und nachvollziehbar sind. Wählt Namen so, dass jeder, der das UI-Repository mit der Absicht, es zu aktualisieren, durchsucht, das UI-Objekt leicht finden kann. Im folgenden Beispiel zeige ich dir eine solche Situation.
Wie erstellt man Object Repositories (Beispiele)
Jetzt schauen wir uns an, wie man am besten und schnellsten mit Object Repositories loslegen kann. Tools wie UFT, IBM RFT, UiPath Test Automation Suite und Power Automate verfügen bereits über Object Repositories. Worauf wartest du also? Glaub mir, es ist super einfach!
Hier ein Beispiel, bei dem ich ein OR in Bezug auf die QAL-Website erstellt habe:
Beachte das obenstehende UI – ich habe alle Widgets, die für Aktionen auf der Login-Oberfläche benötigt werden, zusammen gruppiert, da sie in mehreren Testfällen gemeinsam verwendet werden. Danach habe ich die Navigationslinks zusammengefasst. Wenn wir diese Objekte gruppiert aufzeichnen, werden alle Testskripte zu Beginn auf diese Gruppe von UI-Link-Objekten zugreifen, sodass diese wiederverwendet werden können, anstatt sie immer wieder neu zur Repository hinzuzufügen.
Beispiel für die Nutzung des Object Repository in UiPath
So sieht das Object Repository im UiPath-Tool aus:
In diesem Beispiel eines Object Repository habe ich die "Login Page"-Objekte in einem Set und die "Main Navigation Links" in einem anderen Set organisiert. Wenn ich jetzt mehrere Testskripte erstellen möchte, um die Login-Seite zu testen, würden alle Testskripte auf dieselben Objekte zugreifen, die ich in die "Login Page" gelegt habe.
Beispiel für die Nutzung des Object Repository in PowerAutomate
So sieht das Object Repository im PowerAutomate-Tool aus:
Wie bereits erwähnt, ist für Wiederverwendbarkeit auch die Benennung der Objekte entscheidend, damit diese später einfach auffindbar sind. Schau dir das UI-Objekt “meprmath_quiz” an. Anders als bei den anderen Feldern ist nicht leicht ersichtlich, auf welches UI-Objekt es sich bezieht. In einem Fall wie diesem, auch wenn beim Hinzufügen des UI-Objekts für das "Quiz"-Textfeld der Feldname “meprmath_quiz” angezeigt wurde, könnten wir es vielleicht als "login_add" benennen, um das Objekt leichter bei der Automatisierung und Wartung des OR auffinden zu können.
Fazit
Wie nutzt du das OR in deinem bevorzugten Testautomatisierungstool? Teile deine Erfahrungen gerne mit uns!
Ich hoffe, dieser Artikel hilft dir zu verstehen, wie das OR dem Team langfristig hilft. Wir können uns glücklich schätzen, dass wir in einer Zeit leben, in der die meisten Testautomatisierungstools die OR-Funktion bereits enthalten. Deshalb musst du nur noch herausfinden, wie sie in deinem Lieblingstool funktioniert!
Hast du in diesem Artikel Neues gelernt? Wenn du mehr solcher Beiträge lesen möchtest, vergiss nicht, den The QA Lead Newsletter zu abonnieren!
Empfohlene Artikel:
Verwandte Liste von Tools: PERFORMANCE-TESTING-SOFTWARE FÜR QA-TEAMS
Ebenfalls empfehlenswert:
