Testautomatisierung mit der Jira App Xray

Anforderung beschreiben

Nehmen wir an, wir wollen einen Online-Shop entwickeln und hier als Beispiel die Login-Funktion automatisiert testen.

Der Anforderer hat dazu bereits eine User Story erstellt: DXRP-23

In unserem Beispiel verwenden wir für die Anforderungen ein separates Anforderungsprojekt in Jira. Die Tests und die Testausführungen befinden sich in einem anderen Projekt. Diese Trennung ermöglicht es z. B., separate Berechtigungen für Anforderer und Tester zu vergeben. Der Anforderungsstatus im Screenshot steht auf UNCOVERED, da es zu dieser Anforderung noch keinen Test gibt, der diese abdeckt:

Im Traceability Report (Rückverfolgbarkeitsbericht) von Xray lässt sich gut erkennen, welche einzelnen Anforderungen bereits eine Testabdeckung haben und wie der Teststatus ist. Unsere User Story DXRP-32 ist dem Epic DXRP-31 zugeordnet. So erhält auch das Epic als Überanforderung einen aufsummierten Anforderungsstatus aus allen untergeordneten User Stories.

Um sicherzustellen, dass die beschriebene Funktion später der Anforderung entspricht, wird vor der Entwicklung der neuen Funktion bereits der Test beschrieben. Das ist ein übliches Vorgehen, wenn Tests automatisiert werden sollen. Dabei beschreibt ein Nicht-Entwickler den Test, damit der Entwickler später genau weiß, was die neue Anforderung können muss. Hierbei hat sich zur Beschreibung des Tests die Gherkin-Sprache durchgesetzt, mit der ein Cucumber-Test erstellt werden kann. Gherkin ist eine natürliche Sprache und kann daher nach kurzer Einführung von Nicht-Entwicklern geschrieben werden. In unserem Beispiel haben wir dazu einen Test in unserem separaten Testprojekt erstellt: DXTP-109

Ein Cucumber Test wird mit der Gherkin Sprache beschrieben (Auszug):

GIVEN [Vorbedingung]
WHEN [Aktion]
THEN [Ergebnis]

In unserem Beispiel verwenden wir eine Cucumber-Scenario-Outline. Dies erlaubt es, Testdaten und -ergebnisse direkt in Jira zu verwalten und dem Test mitzugeben:

EXAMPLES:

Das hat den Vorteil, dass beim Ändern der Testdaten kein Entwickler hinzugezogen werden muss, der den Testcode ändert. Zum Beispiel kann so auch der Anforderer selbst die Testdaten verändern oder erweitern.

Ist für eine Anforderung in Jira mindestens ein Test erstellt worden, wechselt der Anforderungsstatus zu NOTRUN.

Im Tracebility Report ist auch diese Änderung sofort ersichtlich.

Der Anforderungs-Status vom Epic bleibt weiterhin auf NOTRUN, da beide Anforderungen mindestens einen Test zur Abdeckung haben und noch kein Test ausgeführt wurde.

Testergebnis auswerten in der Jira App Xray

Bei Cucumber Tests werden die Testergebnisse immer an neuen Test Executions zurückgemeldet. Dafür sorgt die Import Schnittstelle von Xray. In unserem Beispiel wird zunächst die Test Execution DXTP-123 automatisch erstellt und mit dem Cucumber Test DXTP-109 verknüpft. Anschließend wird der Test Status gesetzt, im Erfolgsfall auf PASS.

Sehen wir uns jetzt noch einmal die Anforderung des Login Features DXRP-32 an, dann hat sich durch die letzte Testausführung der Anforderungs-Status zu OK geändert.

Auch im Traceability Report lässt sich jetzt erkennen, das alles grün ist. Daher ist der Anforderungs-Status des Epics ebenfalls OK. Voraussetzung dazu ist, dass alle aktuellen Testausführungen der Tests erfolgreich waren.

Schlägt auch nur eine Testausführung fehl, so zieht sich diese Information bis zum Epic nach oben durch.