Testvorbereitung

Zur Unterstützung der Testvorbereitung bietet TestOrbit einige sehr hilfreiche Funktionalitäten an, die nachfolgend beschrieben werden.

Repository Editor

Unter dem Begriff „Repository“ bietet TestOrbit einen zentralen Pool zur „Ablage“ von wichtigen Ressourcen an, die in vielen Testfällen verwendet werden können.

Ein konkretes Nutzungsszenario dafür ist die zentrale Definition von UI Objekt-Lokatoren zur Identifizierung und Interaktion mit Elementen der zu testenden UI Oberflächen (nach dem Page Object Model Pattern).

Für diesen wichtigen Use Case (Verwaltung von UI Lokatoren) wird eine spezielle, benutzerfreundliche Repository Editor Oberfläche bereitgestellt, die hier näher erläutert wird.

Verwaltung der Repositories

Alle Funktionalitäten zur Verwaltung und Bearbeitung von Repositories erreicht man am schnellsten über den Navigationsmenüpunkt „Repositories“ (s. Abb. 1 4).

Dadurch wird die Verwaltungsseite mit einer Liste aller verfügbaren Repositories geladen (s. Abb. 2 1).

Jeder Eintrag in der Liste fasst eine bereits angelegte Repository zusammen, die man durch Klick auf die „Delete“ Taste 3 löschen kann. Durch das Anklicken der „Edit“ Taste 2 gelangt man zu der Details Seite, auf der man die Eigenschaften und die Inhalte der Repository bearbeiten kann.

Um eine neue Repository anzulegen, klickt man auf die „Add“ Taste 4.

Neue Repository erstellen und bearbeiten

Nach dem Klick auf die „Add“ bzw. die „Edit“ Taste in der Repository Verwaltungssicht gelangt man zur Repository Details Seite.

Auf dieser Seite kann man sowohl die allgemeinen Repository Eigenschaften wie Namen 1 und Beschreibung 2 vergeben als auch den eigentlichen Inhalt der Repository bearbeiten, der unterhalb des Bereichs „Repository Content“ dargestellt wird 4 (s. Abb. 3.)

Beim Anlegen einer neuen Repository empfiehlt es sich als erstes einen neuen sprechenden Namen 1 für die Repository anzugeben.

Über die Auswahl-Box „Repository Technologie“ gibt man an, welche Art von Daten man in der Repository verwalten möchte. Zurzeit wird nur die Repository Verwaltung der UI Web Lokatoren angeboten, weshalb auch als Technologie bereits der passende Eintrag „Web Application“ ausgewählt ist 3.

Eine neue Repository ist anfangs leer und enthält noch keine Einträge im Bereich „Repository Content“. Zum Anlegen der initialen Einträge stehen die Tasten „Add Repository Page“ und „Add Repository Item“ zur Verfügung 4. Die nachfolgenden Abschnitte beschreiben detailliert die Vorgehensweise bei der Strukturierung und Befüllung der Repository Inhalte.

Strukturierung der Repository via Repository Pages

Der Repository Editor bietet eine praktische Möglichkeit an die Inhalte einer Repository in einem hierarchischen Baum (bestehend aus Repository Pages als Äste und Repository Items als Blätter) strukturiert abzulegen (s. Abb. 4 1). Jede „Repository Page“ dient dabei als Container 2, der sowohl einzelne Repository Items 4 als auch weitere Sub-Pages enthalten kann 3, die wiederum ihrerseits auch weitere Sub-Pages auf tieferen Ebenen enthalten können. Auf diese Weise kann ein hierarchischer Baum mit mehreren Ebenen erstellt werden, der den logischen Aufbau einer zu testenden Applikation, z.B. eines Web Portals, nachvollziehbar und strukturiert abbilden kann, was die Verwendung und Zuordnung in Testfälle signifikant erleichtert.

Die Verwaltung solcher Repository Strukturen erfolgt mittels der nachfolgend beschriebenen Funktionalitäten (s. Abb. 4):

• Zum Anlegen einer Page auf der obersten Ebene (Top-Level Page 2) klickt man auf die „Add Page“ Taste 5 unterhalb des Baums.
• Zum Anlegen einer Sub-Page 3 innerhalb einer existierenden Page schwebt man den Mauszeiger oberhalb einer Page, die als Elternteil fungieren soll und klickt anschließend auf die eingeblendete Taste „Add Repository“ 7 nebenan.
• Zum Anlegen eines Items auf der obersten Ebene (Top-Level Item) klickt man auf die „Add Item“ Taste 6 unterhalb des Baums.
• Zum Anlegen eines Sub-Items innerhalb einer existierenden Page schwebt man den Mauszeiger oberhalb einer Page, die als Container für dieses Element fungieren soll und klickt anschließend auf die eingeblendete Taste „Add Item“ 8 nebenan.
• Über die eingeblendeten Tasten „Clone“ 9 und „Delete“ 10 kann man außerdem die einzelnen Pages und Items klonen bzw. löschen.

---

Achtung:

Beim Löschen einer Page werden dabei alle darin enthaltene Sub-Pages und Items rekursiv gelöscht. Falls die betroffenen Items immer noch in existierenden Testfällen referenziert werden, schlägt die Testdurchführung fehl und beim Laden dieser Testfälle im Test Case Designer werden die ungültigen Repository Item Referenzen rot markiert.

---

Hinweis:

Die Speicherung der einzelnen Repository Elemente in einem hierarchischen Page-Baum folgt dabei einem weit verbreiteten und bewährten „Page Object Model“ Pattern (kurz „POM“) zur zentralisierten und strukturierten Ablage von UI Lokatoren mit dem Ziele die Wartbarkeit der automatisierten Oberflächentests deutlich zu verbessern.

---

Als Best-Practice empfiehlt sich folgende Vorgehensweise bei der Strukturierung einer Repository:

• Software-under-Test Applikation in funktionale Bereiche aufteilen (z.B. Kundenverwaltung, Artikelverwaltung usw.) und für jeden dieser Bereiche eine Top-Level Page im Repository anlegen
• Innerhalb eines funktionalen Bereichs logische Einheiten identifizieren (z.B. zugehörige Webseiten) und für jede Einheit entsprechende Sub-Pages innerhalb einer Top-Level Page erstellen
• Im Fall von sehr komplexen logischen Einheiten bietet es sich an weitere Sub-Pages für einzelne Fragmente einer komplexen Einheit anzulegen (z.B.  Teilbereich einer Webseite)
• Die konkreten Elemente, z.B. UI Objekte auf der Webseite bzw. auf dem Fragment der Webseite, erfasst man dann unmittelbar innerhalb der Sub-Page, die man für diesen Bereich in vorherigen Schritten vorbereitet hat
• Zur Vermeidung von überfrachteten UI Repositories empfiehlt es sich nicht alle möglichen visuellen UI Elemente einer Webseite oder Desktop Applikation zu erfassen, sondern nur die zentralen Interaktionsobjekte, die in Tests verwendet werden. So kann man i.d.R. auf die Erfassung von vielen Text-Beschriftungen verzichten, es sei denn es ist expliziter Bestandteil der Testvalidierung.
• Bei der Benamung der Repository Pages und Repository Items ist es von zentraler Bedeutung nachvollziehbare Bezeichnungen zu wählen, damit man bei der späteren Verwendung in Testfällen sofort die Bedeutung dieser Items erschließen kann. Solange die Items in einer sauberen Page-Hierarchie angelegt werden, können sie problemlos gleiche Namen haben, wie z.B. „btnOK“.

Erfassung von Repository Items

Sobald man ein neues Repository Item zu einer Repository Page hinzufügt oder ein bestehendes Item auswählt, wird auf der rechten Seite des Repository Editors ein „Repository Item Editor“ eingeblendet.

Für die Repository Items der Web Repositories bietet „Repository Item Editor“ folgende Eingabemöglichkeiten an (s. Abb. 5):

1 Repository: Ablageort/Pfad des aktuellen Items im Repository Baum. Die Anzeige ist schreibgeschützt. Der Pfad lässt sich über einen speziellen Dialog durch den Klick auf die „Edit“ Taste 7 bearbeiten.

2 Name: Logische/fachliche Bezeichnung des Items, die später in vielen Testschritten referenziert wird. Aus diesem Grund ist ein sprechender, nachvollziehbarer Name sehr wichtig.

3 Description: Detaillierte Beschreibung des Items, z.B. für welche fachliche Aktion es verwendet wird.

4 Element Type: Technischer Typ des UI Objekts. Zurzeit steht für Web Oberflächen nur ein Element Type vom Typ „Selenium Element“ zur Verfügung, weil die Objektsuche und Interaktion intern über den weitverbreiteten Selenium Driver erfolgt.

5 Identification Method: Auswahl des Verfahrens für die Suche nach UI Objekten.

6 Identifier: Angabe des technischen Identifikationsmerkmals des zu findenden Elements abhängig von der gewählten Identifikationsmethode (z.B. XPath Pfad oder technische ID des Elements)

Bei der Auswahl der Methode zur Objektidentifizierung werden folgende Möglichkeiten angeboten:

• Suche über eindeutige ID
• Suche über eindeutigen Namen
• Suche über ein Fragment des Inhalts
• Suche über einen Bestandteil der CSS Klasse
• Benutzerdefinierte, flexible Suche über einen XPath Ausdruck

Alle Änderungen, die im Repository Item Editor vorgenommen werden, müssen durch Klick auf die Taste „Save“ 8 persistiert werden.

---

Hinweis:

Die Entscheidung, anhand welcher Methode und Identifier ein UI Element am besten erkannt werden kann, entnimmt man entweder aus dem DOM Baum der relevanten Webseite in „Web Browser Developer Tools“ der gängigen WE Browsern oder konsultiert die Web-Entwickler der zu testenden Web Applikation.

Es empfiehlt sich, wann immer es möglich ist, eine stabile und eindeutige ID- bzw. namensbasierte Objekterkennung zu wählen und diese zu verwenden. Sofern diese Optionen nicht zur Verfügung stehen, können die (CSS) Klassen oder Inhaltsbestandteile für die Objektidentifizierung benutzt werden. Im multilingualen Kontext kann jedoch die inhaltsbasierte Suche zu unerwünschten Instabilitäten führen, daher sollte diese nur mit Vorsicht eingesetzt werden. Wenn alle diese einfachen Methoden nicht anwendbar sind, kann ein benutzerdefinierter XPath Ausdruck zur eindeutigen Suche nach einem gewünschten Objekt angegeben werden.

---

Hinweis:

Der große Vorteil bei der Verwendung von Repository und Speicherung der zu testenden Oberflächenelement als Repository Items in der Repository besteht darin, dass man die technischen (potentiell aufwändigen) Methoden zur Identifizierung dieser Element nur ein einziges Mal zentral pro Applikation in einer Repository persistiert und anschließend diese Elemente in Testfällen nur über ihren abstrahierten, fachlichen (nicht-technischen Namen) anspricht. Auf diese Weise können auch weniger technisch erfahrene Automatisierer die bestehenden Repository Items beim Test Design verwenden, ohne sich um die technischen Verfahren der jeweiligen Objekterkennung zu kümmern. Mindestens genauso wichtig ist auch eine deutlich verbesserte Wartbarkeit der Tests, da im Fall der Änderungen der zu testenden Oberflächen im Optimalfall die technischen Identifier der relevanten Elemente nur ein einziges Mal zentral in der Repository angepasst werden müssen, um dadurch eine Vielzahl von betroffenen fehlgeschlagenen Tests wieder lauffähig zu bekommen, ohne sie zu modifizieren.

---

Datengetriebene Repository Items

Zur weiteren Verbesserung der Wartbarkeit der Testfälle und zur Minimierung der Anzahl der zu erfassenden UI Steuerelemente, bietet der Repository Item Editor eine sehr hilfreiche Möglichkeit an, sogenannte „datengetriebenen“ Repository Items anzulegen. Im Grunde genommen handelt es sich um ganz normale Repository Items, die jedoch in der technischen Identifier Deklaration nicht einen „voll ausgeschriebenen“ exakten Element Lokator enthalten, sondern zusätzlich einen Platzhalter-Parameter enthalten.

Dies kann vor allem in folgenden Situationen sehr nützlich sein:

• Container-Elemente kompakt erfassen: Viele Web Oberflächen beinhalten sogenannte Container Strukturen, wie z.B. Listen. Dabei fungiert die Liste als ein Container Element, das viele einzelne Sub-Elemente als Ausprägungen enthält, wie z.B. eine Sprachauswahl-Box mit vielen Sprachen. Um in verschiedenen Testfällen auf diverse Sprachen in dieser Box zuzugreifen, könnte man natürlich jeden einzelnen Spracheintrag einzeln als Repository Item erfassen. Das wäre jedoch sehr umständlich und würde die Größe der Repository unnötig sprengen. Mit Hilfe der Datengetriebenen Repository Items erfasst man stattdessen nur ein einziges Element dieser Liste in der Repository – und zwar als einen generischen Eintrag mit einer Platzhalter Variable für eine konkrete Ausprägung. Diese Platzhalter-Variable wird dann während der Testdurchführung durch den im Testfall spezifizierten Wert der gleichen exakten (datengetriebener) Variable ersetzt, so dass erst zur Laufzeit ein exakter und vollständiger Identifier gebildet wird, über den eine konkrete Ausprägung des Elements im Container gefunden werden kann.
  [ Beispiel: //*[@data-uia=‘language-picker‘]/option[@label=‘${LanguageName}‚] ]
• Indizierte Elemente kompakt erfassen: Viele Webseiten können bestimmte Elementgruppen bilden, die intern als eindeutige Bestandteile den fachlichen Bezeichner der Gruppe in ihrem Suffix haben (z.B. Kacheln). In diesem Fall handelt es sich nicht um einfache Container, sondern um komplexe hierarchische DOM-Teilbäume. Dennoch kann man auch in diesem Fall die parametrisierte Identifier-Deklaration verwenden, um den instabilen, „datengetriebenen“, fachlichen Teil des gesuchten Gruppen-Elementes zu erfassen. Während der Testdurchführung wird dann dieser „unscharfe“ Teil des Identifiers anhand von Testdaten des Testfalls aufgelöst, um einen vollständigen Identifier zu bilden.
  [ Beispiel: //*[@id=‘article_${ArticleName}] ]

Das Anlegen eines datengetriebenen Repository Items gelingt am einfachsten aus dem Test Case Designer heraus, weil hier automatisch die im Testfall deklarierten Testdaten-Parameter ausgelesen werden und im Repository Item Editor über die „Show“ Taste 1 zur Verwendung im Identifier Feld angeboten werden (s. Abb. 6).

Repository Items verschieben

Der Repository Item Editor bietet weiterhin die Möglichkeit an, das aktuell ausgewählte Repository Item zu verschieben, und zwar

• entweder innerhalb der gleichen Repository in eine andere Page
• oder in ein anderes Repository

In beiden Fällen muss man auf die Edit Taste neben dem Repository Pfad klicken (Abb. 5 7). Daraufhin öffnet sich ein „Repository Item Picker“ (s. Abb. 7), in dem der aktuelle Pfad des Items gezeigt wird 1 und durch die Auswahl einer anderen Page 2 der neue „Ort“ für die Speicherung des Repository Items festgelegt wird. Durch Klick auf die Taste „Apply“ 3 bestätigt man die Auswahl und kehrt zum Repository Item Editor zurück, wo man anschließend unbedingt durch den Klick auf Taste „Save“ die Änderungen persistieren muss.

Zum Verschieben des Items in eine andere Repository geht man analog vor, wählt aber als Erstes in „Repository Item Picker“ eine andere Repository aus 4.

Verwendung einer Repository

Eine Repository samt ihren Repository Pages und Repository Items wird initial zentral erstellt, um die dort definierten Elemente vielfach über ihren logischen Namen in den Testfällen zu verwenden, und zwar in den unterstützten Kommandos der Testschritte im Test Case Designer. Die genauere Vorgehensweise wird im Kapitel „Test Case Designer“ genauer beschrieben.

In Hinblick auf den Lebenszyklus von Repository Elementen ist es wichtig festzuhalten, dass in den Testfällen stets nur eine Referenz auf das Repository Item (ID) gespeichert wird. Dadurch kann man alle Eigenschaften des Repository Items, selbst den Namen, ändern, ohne die betroffenen Testfälle anzupassen. Beim nächsten Laden bzw. Ausführen der betroffenen Testfälle werden die Änderungen automatisch angewandt. Dadurch kann man die Repository zu deutlicher Verbesserung der Wartbarkeit der Testfälle einsetzen.

Sobald man eine Repository Struktur, wie z.B. Page, löscht, werden automatisch auch alle darin enthaltenen Repository Items gelöscht, so dass sie nicht mehr in den Testfällen verwendet werden. Die Testdurchführung wird in diesem Fall fehlschlagen und beim Laden eines solchen Testfalls im Test Case Designer wird das Kommando, welches das gelöschte Repository Item referenziert, rot markiert.

BDD Szenario Definition

Als ein weiteres wichtiges Element zur Unterstützung einer frühen und effizienten Testautomatisierung unterstützt TestOrbit die in agilen Projekten weit verbreitete BDD/TDD Arbeitsweise. Bei dieser Vorgehensweise fängt die Umsetzung eines neuen Features bereits zum frühestmöglichen Zeitpunkt (z.B. im Rahmen einer „3 Amigo Session“) mit der Definition der konkreten fachlichen Test Szenarien an, die als Grundlage für die darauf folgende Testautomatisierung dieser Szenarien und die Implementierung der jeweiligen Funktionalitäten in der Business Applikation dient.

Der Vorteil dieser Vorgehensweise (die auch als „Test First“ Ansatz bezeichnet wird) besteht darin, dass alle an der Feature Bereitstellung beteiligten Rollen, wie Developer, QA, PO/Analyst, an der Besprechung der Feature-Anforderungen beteiligt sind und zusammen ganz früh in dem SW Entwicklungsprozess die erforderlichen konkreten Testfälle ableiten, die zu deutlich besserem gemeinsamen Verständnis der Anforderungen und Akzeptanzkriterien beitragen und so nachträgliche teure Umbau-Maßnahmen vermeiden.

Um diese Vorgehensweise zu unterstützen, bietet TestOrbit eine sehr bequeme Möglichkeit an, die fachlichen (logischen) BDD Szenarien in der etablierten Gherkin Notation im Test Case Designer gleich von Anfang an als Testfall-Ablauf abzubilden, ohne sofort die technische Testautomatisierung vorzunehmen. Dadurch können alle Beteiligten der 3-Amigo Session an der Definition von solchen Testfällen im SimplyTest Test Case Designer arbeiten, selbst wenn sie keine fundierten Skills im Bereich der Testautomatisierung mitbringen. Die technische Automatisierung übernimmt anschließend ein erfahrener QA oder Developer.

Die Besonderheiten der Umsetzung dieses Verfahrens in TestOrbit werden nachfolgend erläutert:

• keine Tool-Brüche: sowohl die Definition von Szenario Spezifikationen als auch die Implementierung der Automatisierungsschritte erfolgt in einem Tool, und zwar an einer Stelle.
• enge automatische Kopplung: dadurch, dass die technische „Implementierung“ eines Automatisierungsschrittes unmittelbar an dem „logischen“ Gherkin Schritt hängt, entsteht eine enge nahtlose Kopplung an einer Stelle, die das Auffinden der Implantierung des Automatisierungsschrittes stark vereinfacht und eine in anderen Frameworks übliche „Verknüpfung“ über fehleranfällige „reguläre Ausdrücke“ völlig überflüssig macht. Aus diesem Grund kann die Benamung der logischen Schritte in der Gherkin Sprache jederzeit angepasst werden, um z.B. die Formulierungen verständlicher zu formulieren, ohne dass dadurch das Mapping mit Automatisierungsschritten zerstört wird.

Damit können agile Teams bereits ganz am Anfang der Sprint Zyklen mit der Definition Ihrer BDD Szenarien in TestOrbit starten und im 2. Schritt mit der Automatisierung dieser Szenarien fortfahren. Abb. 8 zeigt ein Beispiel für eine mögliche BDD Szenario Beschreibung in Test Case Designer (ohne technische Automatisierungsimplementierung). Eine detailliertere Anleitung zur Definition neuer Testfälle lesen Sie im Kapitel „Test Case Designer“.