Tests sind fertig! – von Pyramiden, Kriterien und Gurken

Photo of author
Timm Uibel

Warum es wichtig ist, ein gemeinsames Verständnis der Tests zu bekommen und wie das mit Akzeptanzkriterien und Gherkin gelingen kann, erfahren Sie hier.

In Projekten hören wir regelmäßig einen Satz wie „Tests sind fertig!“. Und wenn dieser Satz nicht fällt, dann kommt idealerweise direkt die Frage „Und wie schaut es mit den Tests aus?“.
Und warum muss darüber geschrieben und gesprochen werden?
Wie oft im Leben, meinen und verstehen verschiedene Personen denselben Satz unterschiedlich. Was ist damit gemeint? Insbesondere beim eigentlich klar erscheinenden Satz „Tests sind fertig!“.

Testpyramide

Dazu schauen wir erstmal auf die Testpyramide, um zu sehen welche Personen in welchen Teststufen involviert sind.

Die Testpyramide stellt die Anzahl der Tests in Verbindung mit den Stufen des Testens dar.

Tiefergehende Informationen zu der Testpyramide sind in dem Buch „Succeeding with Agile: Software Development Using Scrum“ von Mike Cohn („Erfinder“ der Testpyramide) zu finden.

Entwicklerin

Teststufe: Komponententest, Integrationstest

Meint: Ich habe Unit- und Integrations-Tests geschrieben. Die Tests decken den Code ab. SonarQube „meckert“ nicht. 😉

Erwartet: Die Software wird nachher noch mal von vielen Beteiligten getestet.

Testerin

Teststufe: Integrationstest, Systemintegrationstest (manuell, automatisiert)

Meint: Ich habe Systemtests geschrieben und durchgeführt. Ich habe keine besonderen Abweichungen gefunden.

Erwartet: Die Unit- und Integrations-Tests sind fehlerfrei durchgelaufen.

UX-Testerin

Teststufe: Systemintegrationstest, Abnahmetest (Oberflächentests)

Meint: Die Anwendung ist einfach, verständlich und intuitiv bedienbar. Die Oberfläche entspricht den Vorgaben.

Erwartet: Die Komponenten sind fehlerfrei. Die systemübergreifenden Tests waren erfolgreich.

Last- und Performance-Testerin

Teststufe: Systemintegrationstest, Abnahmetest (nicht Oberflächentests, sondern eher Schnittstellen aufrufe, z.B. REST-Calls)

Meint: Die Anwendung arbeitet schnell. Sie kann hohe Last aushalten und ist auch für zukünftige Lasten und Datenmengen gerüstet. Ist robust gegen Lastspitzen.

Erwartet: Die Komponenten sind fehlerfrei. Die systemübergreifenden Tests waren erfolgreich.

Security-Testerin:

Teststufe: Integrationstest, Systemintegrationstest, Abnahmetest

Meint: Die Anwendung ist sicher. Angriffslücken wurden nicht gefunden. Die Komponenten sind auf dem aktuellen Stand. Potenzielle Angreifer werden es schwer haben.

Erwartet: Die Komponenten sind fehlerfrei. Die systemübergreifenden Tests waren erfolgreich.

Abnahmetesterin / Fachexpertin

Teststufe: Abnahmetest, auch explorative Tests

Meint: Alle Geschäftsfälle funktionieren; die Neuen und auch alle Bisherigen.

Erwartet: Die Unit- und Integrationstest sind fehlerfrei durchgeführt worden. Die systemübergreifenden Tests waren erfolgreich.

Product-Owner

Teststufe: Abnahmetest, auch explorative Tests

Erwartet: Die Anwendung wurde geprüft und entspricht den Anforderungen.

Managerin

Teststufe: Abnahmetest (z.B. kontrollieren und genehmigen des Testergebnisberichts)

Erwartet: Die Anwendung funktioniert fehlerfrei und kann vollumfänglich, einfach und wie gewünscht genutzt werden.

Kommunikationsprobleme

Durch die teilweise unterschiedlichen Auffassungen und damit verbundenen Erwartungen über den Satz „Die Tests sind fertig!“ kann es unter den Beteiligten Kommunikationsprobleme und damit auch Konflikte geben.

Dass für die verschiedenen Personengruppen die Tests nicht immer transparent sind, erschwert das Aufbauen eines gemeinsamen Verständnisses. Z.B. haben Fachexpertinnen häufig keinen Zugang zu den Unit-Tests oder haben als Nicht-Entwicklerinnen Probleme die programmierten Tests nachzuvollziehen. Und andererseits ist den Entwicklerinnen beim Umsetzen einer Komponente nicht immer transparent und bewusst, welche Geschäftsfälle davon betroffen sind. Auch sind Erwartungen nicht immer transparent; insbesondere die nicht-funktionalen Anforderungen, wie Performanz-, Last- oder Sicherheitserwartungen.

Akzeptanzkriterien

Um diese Kommunikationshindernisse zu minimieren, bietet es sich an Anforderungen / User-Stories um einen Abschnitt mit den Akzeptanzkriterien anzureichern und diesen mit Inhalten zu füllen.

Die Akzeptanzkriterien definieren Bedingungen, durch die eine Anforderung erfüllt und vom Anforderer akzeptiert wird. Akzeptanzkriterien konkretisieren Anforderungen.

Dabei sollte darauf geachtet werden, dass die Kriterien prägnant und für alle Beteiligten verständlich formuliert sind, denn nur so können die potenziellen Missverständnisse zwischen den Beteiligten beseitigt werden. Das bedeutet zum Beispiel auch, das die Kriterien nicht zu technisch sein sollten und kryptische, nicht eindeutige Abkürzungen vermieden werden müssen.

Akzeptanzkriterien mit Gherkin

Um die Akzeptanzkriterien verständlich und strukturiert aufzuschreiben, hat sich die Beschreibungssprache Gherkin (zu deutsch: Gurke) bewährt.

Es kann eine Hilfe für Expertinnen, Product-Owners und Requirement-Engineers sein, Anforderungen und Erwartungen strukturiert aufzuschreiben. Manchmal fällt dann auf, dass Informationen noch fehlen oder nicht eindeutig formuliert sind.

Und für Entwickler kann es eine Erleichterung sein, genau zu wissen was erwartet wird. Häufig kann der in Gherkin verfasst Test genutzt werden, um Testfälle zu programmieren (z.B. mit Cucumber).

Und Testerinnen können die in Gherkin geschriebenen Akzeptanzkriterien als Testfall mit Schrittbeschreibung verwenden.

Gherkin – einfaches Beispiel

Feature: Rights check Only administrators can change or delete products Scenario: Anna changes a product name Given I am logged in as Anna When I try to change the name of the product with id 1234 to “Currywurst” Then I should see the name “Currywurst“ for the product with the id 1234
Code-Sprache: Gherkin (gherkin)

Gherkin-Schlüsselwörter

Die Beschreibungssprache enthält Schlüsselwörter, um Akzeptanzkriterien und Testfälle zu strukturieren.

Die für Akzeptanzkriterien wichtigsten Schlüsselwörter sind:

Feature: Ist eine grobe Beschreibung, worum es fachlich geht.

Rule (ab Gherkin 6): Das beschreibt eine Geschäftsregel und wird zum Gruppieren von Szenarien verwendet.

Example (oder Scenario):  Ist der prägnante Titel des Akzeptanzkriteriums.

Given: Das beschreibt eine Vorbedingung.

When: Das beschreibt die Aktion, die ausgeführt werden muss.

Then: Das beschreibt das erwartete Ergebnis.

And (oder But): Diese beiden Schlüsselwörter dienen zur Verbindung von mehreren Vorbedingungen, Aktionen oder Ergebnissen.

Darüber hinaus gibt es auch weitere Schlüsselwörter, die teilweise etwas entwicklungsnäher sind und auf eine Automatisierung abzielen.

Background: Hier können Vorbedingungen, die für alle Szenarien notwendig sind, notiert werden, damit die einzelnen Szenarien nicht so lang und unübersichtlich werden.

Scenario Outline (oder Scenario Template): Das beschreibt ein Szenario, bei dem Teile durch Variablen ersetzt werden. Und die Werte werden beim Schlüsselwort „Examples“ notiert.

Examples: Ist eine Tabelle mit den Variablen in der Zeile und den Variablenwerten in den Zeilen darunter.

Gherkin – erweitertes Beispiel

Feature: Pub math Background: Given the pub is open And the beer keg is not empty Scenario: drink 5 out of 12 Given there are 12 beers When I drink 5 beers Then I should have 7 beers Scenario: drink 5 out of 20 Given there are 20 beers When I drink 5 beers Then I should have 15 beers
Code-Sprache: Gherkin (gherkin)

Die beiden Szenarien können durch Variablen vereinfacht dargestellt werden, sodass das Akzeptanzkriterium nur einmal aufgeschrieben muss und die konkreten Ausprägungen in einer Tabellenform notiert werden können. Insbesondere bei Anforderungen mit hohem Anteil an Berechnungen oder Logik bietet sich diese Notation an.

Feature: Pub math Background: Given the pub is open And the beer keg is not empty Scenario Outline: drinking Given there are <start> beers When I drink <drink> beers Then I should have <left> beers Examples: | start | drink | left | | 12 | 5 | 7 | | 20 | 5 | 15 |
Code-Sprache: Gherkin (gherkin)

Gherkin international

Um Gherkin in der jeweiligen Muttersprache zu verwenden, ist es auch möglich Schlüsselwörter in über 70 Sprachen zu verwenden.

So können die Fachexpertinnen in der vereinbarten Projektsprache schreiben und die Entwicklerinnen die Akzeptanzkriterien für die Tests ohne Übersetzungsleistungen verwenden.

# language: de Feature: Benutzeranmeldungen und Berechtigungen Szenario: Als registrierter Benutzer einloggen Gegeben sei dass die Webseite http://automationpractice.com/ aufgerufen ist Und kein Benutzer eingeloggt ist Und ein Benutzer existiert Wenn die E-Mail-Adresse im Feld “Email Address” eingegeben wird Und das Passwort im Feld “Password” eingegeben wird Und auf den Button “Sign In” gedrücktt wird Dann wird rechts oben der Benutzername angezeigt
Code-Sprache: Gherkin (gherkin)

Fazit

Wenn alle Beteiligten das Wissen über Tests der anderen Stufen haben und mit dem strukturierten Aufschreiben der Akzeptanzkriterien – z.B. in Gherkin –  vertraut sind, dann kann leicht ein gemeinsames Verständnis erzeugt werden, sodass der Satz „Tests sind fertig!“ richtig eingeordnet werden kann.

Darüber hinaus sorgen Akzeptanzkriterien dafür, sich frühzeitig mit den Erwartungen der Anforderung zu befassen. Wenn dadurch weniger Missverständnisse entstehen und man schneller zu Tests oder gar zu automatisierten Tests kommt, kann dann das Projekte nur von Vorteil sein. Sowohl zeitlich, als auch monetär.

Einfach mal über die Tests der Teststufen sprechen und Akzeptanzkriterien mit Gherkin ausprobieren!

Schreibe einen Kommentar

Das könnte Dich auch noch interessieren

Interview: Ende-zu-Ende Testing von Microservices

Interview: Ende-zu-Ende Testing von Microservices

Meine Erfahrungen basierend auf Eindrücken aus einem groß angelegten Projekt mit über 70 Microservices und mehr als 15 Teams findest ...
Weiterlesen
Die Anatomie von CQRS in Java

Die Anatomie von CQRS in Java

Aufgrund meiner festen Überzeugung, dass man Patterns am besten lernt, wenn man sie zunächst einmal selbst implementiert hat, erläutere ich ...
Weiterlesen
Selbststeuerung

Selbststeuerung

Habt Ihr "Pseudo-Scrum" ebenfalls schon mal erlebt? Wie es anders geht und welche Rolle die Entwickler dabei spielen, erfahrt ihr ...
Weiterlesen