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.

 

Testpyramide

 

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

 

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

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   |

 

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ückt wird
   Dann wird rechts oben der Benutzername angezeigt

 

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!