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ückt 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!