Techblog

Session-Sheets in Jira verwenden

Von Florian Pilz @Flo_Pilz auf Twitter
9. November 2020

In unseren Projekten setzen wir im Testing auf eine Kombination aus Testautomatisierung und Session-Based-Testing. Die Testautomatisierung soll gegenüber Regressionen absichern, das Session-Based-Testing prüft ein Feature auf Herz und Nieren.

 

Session-Based-Testing (SBT)

SBT basiert auf explorativem Testing. Exploratives Testen laut satisfice.com

“is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modeling, observation and inference, output checking, etc.”

Mehr Informationen zum explorativem Testen finden Sie im Blog von Marcel Gehlen

Ein Problem ist jedoch die Nachvollziehbarkeit – was wurde getestet, wie wurde getestet, was waren die Ergebnisse. In klassischen Testfällen sieht man auf einen Blick, ob der Test erfolgreich war oder nicht.

Dieses Problem löst das SBT durch sogenannte Session-Sheets. Diese beschreiben

  • Wer?
  • hat wann?
  • mit welchen Daten?
  • auf welcher Umgebung/ Browser/…?
  • auf welche Weise?
  • welche Funktion getestet?
  • Und was kam dabei heraus?

Eine Schwierigkeit in unseren Projekten ist immer wieder, wie diese Session-Sheets abgelegt werden. Schließlich soll schnell eine Rückmeldung über den aktuellen Stand der Funktionen möglich sein. Ebenso soll nachvollziehbar sein, was bereits wie getestet wurde. Auch helfen frühere Session-Sheets, um Ideen für neue Sessions zu generieren.

 

Integration von Session-Sheets in Jira Xray

In einem unserer Projekte haben wir die Session-Sheets in Jira abgelegt:

  1. In Confluence wurde ein Ordner für die Session-Sheets angelegt. Unterordner entsprachen den verschiedenen Hauptfeatures.
  2. Zu jeder Session wurde ein Session-Sheet als Seite in dem entsprechenden Confluence-Ordner erstellt.
  3. Zu jeder User-Story (Jira) wurde ein Testfall in Xray erstellt und mit der User-Story verknüpft. Der Testfall selbst blieb leer.
  4. Die Confluence-Seite wurde mit dem Testfall in Xray verlinkt. Dadurch ergab sich eine Beziehung Session-Sheet <> Testfall in Xray <> User-Story.
  5. Die Ergebnisse wurden in einem Session-Review mit POs und Entwicklern besprochen: sind die Befunde tatsächliche Bugs oder so gewünscht bzw. werden in späteren Tickets bereits angepasst.
  6. Abschließend wurde ein Test-Run in Xray erstellt, welcher den Status „Passed“ oder „Fail“ bekam, je nach Ergebnis der Session und des Reviews.

Wurden mehrere Sessions zu einer User-Story durchgeführt, wurden diese ebenfalls im Confluence angelegt und mit demselben Testfall verknüpft. Das war beispielsweise der Fall, wenn mehrere Szenarien separat getestet wurden (mehr in diesem Blog). Zu jeder dieser Testausführungen wurde wieder ein Test-Run erstellt, wie oben unter 6. beschrieben. So war die Nachvollziehbarkeit über mehrere Sessions hinweg gegeben.

Nachvollziehbarkeit vs. Aufwand

Die dargestellten Schritte brachten einigen Aufwand mit sich, da sie manuell ausgeführt werden mussten. Dies fiel gerade bei kleinen User-Stories mit nur sehr wenig Testaufwand auf.

Allerdings konnte auf diese Weise die Nachvollziehbarkeit der Testaktivitäten hergestellt werden. Durch die Verknüpfung der User-Stories mit den Testfällen und Test-Runs konnte erkannte werden, welche User-Stories bereits getestet wurden und was das jeweilige Ergebnis war. Durch die zusätzliche Verknüpfung mit den Session-Sheets im Confluence war schnell ersichtlich, wie getestet wurde. Dadurch konnte nicht nur nachvollzogen werden, was alles nicht funktionierte, sondern auch was korrekt umgesetzt wurde.

Die Mitglieder des Teams und die Projektleitung bekamen somit einen schnellen Überblick über den Stand der Testaktivitäten. Aber auch für die Tester und Testerinnen war diese Art der Dokumentation hilfreich. Zum einen konnte bei Bugs nachvollzogen werden, was das Problem war und welche Schritte ausgeführt wurden. Zum anderen sind frühere Sessions hilfreich bei der Generierung von neuen Testideen.

Neuen Kommentar schreiben

Public Comment form

  • Zulässige HTML-Tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd><p><h1><h2><h3>

Plain text

  • Keine HTML-Tags erlaubt.
  • Internet- und E-Mail-Adressen werden automatisch umgewandelt.
  • HTML - Zeilenumbrüche und Absätze werden automatisch erzeugt.

ME Landing Page Question