Testautomatisierung in Azure DevOps

Azure DevOps bietet vieles, was in einem Projekt benötigt wird. So gibt es die Möglichkeit Dokumentationen, agile Boards wie Scrumboards, das Git-Repository und auch die Pipelines in Azure DevOps zu verwalten. Für mich als Testautomatisierer ist natürlich das Testplan-Modul von Interesse.

In diesem Artikel möchte ich beschreiben,

• wie eine Testautomatisierung in Azure DevOps integriert werden kann,
• wie diese automatisiert gestartet werden kann,
• wie die Testergebnisse übersichtlich dargestellt werden können und
• was die Grenzen von Azure DevOps sind. Denn so viel es auch ermöglicht, alles wird doch nicht angeboten.

1. Vorbereitung

Das Testplanmodul bietet die Möglichkeit, verschiedene Konfigurationen und Konfigurationsvariablen anzulegen. Konfigurationsvariablen sind beispielsweise das Betriebssystem, die Testumgebung oder auch der verwendete Browser. Diese Variablen werden zu Konfigurationen kombiniert. So könnte eine Konfiguration “Integrationsumgebung – Windows 10 – Chrome” und eine weitere “Integrationsumgebung – Windows 10 – Firefox” entstehen.

2. Erstellen der Testfälle mit dem Testplan-Modul

Im Testplanmodul werden anschließend die Testfälle erstellt. Um diese zu strukturieren, werden sie in verschiedenen Testsuiten abgelegt. Dabei gibt es drei unterschiedliche Arten von Testsuites:

• statisch: fungieren wie Ordner auf dem Rechner.
• Requirement-basiert: Testfälle, die in diesem Ordner abgelegt werden, werden direkt mit den gewählten Requirement verknüpft.
• Query-basiert: hier werden alle Testfälle angezeigt, die einem erstellten Filter entsprechen.

Testsuiten können sowohl Testfälle als auch weitere Testsuiten beinhalten, so dass beliebig viele Ebenen von Testsuiten erstellt werden können.

Die Testfälle bestehen aus mehreren Schritten mit den jeweiligen erwarteten Ergebnissen. Einzelne oder mehrere Schritte, die immer wieder verwendet werden, können als geteilte Schritte gespeichert werden. Ein Beispiel sind die Schritte für den Login. Dadurch wird immer nur der Schritt “Login“ eingefügt. Ändert sich dieser, so muss der Schritt nur einmal für alle Testfälle angepasst werden.

Die Testsuiten werden anschließend mit den zuvor erstellten Konfigurationen verknüpft. Dies geschieht im Testplan in den Einstellungen der einzelnen Testsuiten.

3. Erstellen der automatisierten Tests

Anschließend werden die automatisierten Testfälle erstellt und in das Git-Repository eingecheckt. In diesem Fall bietet sich die Sprache C# an, da dann die automatisierten Testfälle mit den Testfällen des Testplans verknüpft werden können – dazu mehr gleich. Welches Testframework verwendet wird, bleibt Jedem und Jeder selbst überlassen. Im Fall von C# wären das MSTest, NUint und xUnit.

4. Verknüpfen der automatisierten Testfälle

Azure DevOps bietet die Möglichkeit, die automatisierten Testfälle mit den Testfällen im Testplan zu verknüpfen. Dabei wird eine 1-zu-1-Beziehung hergestellt. Diese Verknüpfung hat den Vorteil, dass die Ergebnisse der Testautomatisierung direkt in Azure DevOps angezeigt werden. Schlägt ein Test fehl, wird das Ergebnis im Testplan direkt am Testfall angezeigt, durch die Beschreibung der Testschritte können diese dann manuell leicht nachgestellt werden.

Ist ein Testfall im Testplan automatisiert, so wird er in den Status „Automated“ versetzt und die verknüpfte Klasse und Funktion wird angezeigt.

Zu beachten ist allerdings, dass die Verknüpfung nur hergestellt werden kann, wenn C# als Sprache und Visual Studio for Windows als IDEE verwendet wird. Alternativ kann dies programmatisch geschehen (siehe zum Beispiel hier)

5. Integration und Ausführen der Testautomatisierung in Azure DevOps

Sind die Testfälle erstellt und verknüpft, dann werden sie in das Git-Modul von Azure DevOps gepusht. Um die Testfälle auszuführen werden sie in einer Azure Pipeline angetriggert. Dazu empfiehlt es sich die Automatisierung als Template zu erstellen (mehr hier). Auf diese Weise kann die Automatisierung in verschiedenen Pipelines eingebunden werden. So kann sie ein Teil der Release-Pipeline werden und zusätzlich als separate Pipeline aufgesetzt werden.

Damit die Ergebnisse korrekt abgelegt werden, werden die benötigten Test-Suiten und die jeweilige Konfiguration angegeben. Auf diese Weise kann beispielsweise später nachvollzogen werden, dass ein bestimmter Testfall auf Umgebung A nicht funktioniert hat, auf Umgebung B jedoch schon.

Variablen wie Nutzernamen, Passwörter und Endpunkte werden in der Library in Azure DevOps abgelegt. Dadurch sind die Passwörter geschützt und alle Variablen können in den verschiedenen Pipelines verwendet werden.

6. Analyse der Ergebnisse

Sind die Testfälle ausgeführt worden, so werden die Ergebnisse an unterschiedlicher Stelle angezeigt.

Zum einen sind die Ergebnisse in der Pipeline unter „Test“ zu sehen. Dort sind die Ergebnisse zu den einzelnen Tests aufgeführt. Ist ein Test fehlgeschlagen, so wird die Fehlermeldung mit angezeigt. Ebenso werden Logs als Datei mit angehängt.

Die meisten Möglichkeiten zur Analyse der Testausführung bietet der Testplan. Zu den einzelnen Testfällen werden pro verknüpfte Konfiguration die Testergebnisse angezeigt. Dadurch kann erkannt werden, ob ein Test beispielsweise im Chrome Browser fehlgeschlagen ist, bei Firefox jedoch funktioniert hat. Ein Doppelklick auf das Ergebnis zeigt die Historie zu den Testdurchläufen pro Testfall und Konfiguration.

Ebenfalls im Testplan befindet sich der Progress-Report. Dieser zeigt die Historie der positiven und negativen Testausführungen, sowie die Anzahl der Tests, die bisher noch nicht ausgeführt wurden. Dieses kann für die unterschiedlichen Testsuiten gefiltert angezeigt werden.

7. Lessons Learned

Azure DevOps bietet viel. Sowohl für die Testautomatisierer, die so ihre Automatisierung leicht integrieren können, als auch für Testmanager, die schnell eine Übersicht über den aktuellen Stand der Automatisierung bekommen möchten. Dies kann natürlich auch für das Team hilfreich sein. Allerdings gibt es auch Einschränkungen.

Wie bereits beschrieben funktioniert die Verknüpfung automatisierter Testfälle und dem Testplan nur mit C# und Visual Studio für Windows. Dass eine Verknüpfung mit anderen Sprachen oder Frameworks wie Cucumber möglich wäre, habe ich bisher nicht gefunden.

Das Reporting bezieht sich jeweils auf den gesamten Testfall. Man sieht also nur, ob Testfälle fehlgeschlagen sind, nicht aber an welchem Schritt. Gerade das kann aber von Vorteil sein, wenn ein einziger Schritt in vielen Testfällen ausgeführt wird und somit eine ganze Reihe von Tests fehlschlagen lässt. Dieses zu erkennen ist etwas aufwändiger.

Wie beschrieben kann im Progress-Report nach den Suiten gefiltert werden. Dieser Filter beinhaltet allerdings keine Suiten, die auf erster Ebene liegen, sondern nur Suiten ab zweiter Ebene. So wird eine Suite „Login“ nicht im Filter angezeigt, eine Suite „Login/correctLogin“ schon.

Logs der einzelnen Tests werden nur dann mit angehängt, wenn ein Testfall fehlschlägt. Manchmal kann es aber trotzdem hilfreich sein, die Testlogs zu sehen, etwa um herauszufinden, ob der Test tatsächlich korrekt abläuft. Dazu muss jedoch ein Test explizit fehlschlagen.

Tests einfach definieren und schnell Überblick bekommen

Azure DevOps ist ein mächtiges Werkzeug. Es bietet den verschiedenen Rollen eines Projektteams (Dev, PO, Test, …) zahlreiche Tools für das tägliche Arbeiten an. Gerade wenn es um die Sichtbarkeit und Analyse der Testautomatisierung geht, kann der Testplan ein hilfreiches Modul sein. Es bietet – mit Einschränkungen – eine leichte und übersichtliche Möglichkeit, Tests zu definieren und im Projekt sichtbar zu machen. Testmanager und das gesamte Team bekommen so eine schnelle Rückmeldung über den aktuellen Stand der automatisierten Tests. Da für das Modul selbst keine Programmierkenntnisse nötig sind, könnten auch andere Rollen wie POs die Tests direkt bei der Erstellung der Stories definieren, welche anschließend von Testautomatisierern automatisiert werden.

---

Über den Autor