Übungsaufgaben zu Akzeptanztests mit Gherkin und Cucumber: Szenarien, Step Definitions und Abnahmeprotokoll für die Mitfahrgesuche

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Akzeptanztests mit Gherkin und
Cucumber: Szenarien, Step Definitions und Abnahmeprotokoll für die
Mitfahrgesuche“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/flurmonitor-akzeptanztest
- https://oer-informatik.de/szenario-mitfahrlabor
- Stilbeispiel: https://oer-informatik.de/flurmonitor-akzeptanztest-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Akzeptanztest
- Abnahmetest
- Gherkin
- Cucumber
- Step Definition
- Szenariogrundriss
- Page Object
- Abnahmeprotokoll
- Sprint Review
- Mitfahrgesuche

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Je Zeile 1 Punkt: Zeilennummern und Aufgabe müssen stimmen.

Es laufen 3 Szenarien: der Szenariogrundriss zweimal (je Zeile der Beispiele) und das Szenario AK-MON-13g.2 einmal. (1 Punkt)

Zu jedem Szenario gehören die 2 Schritte der Grundlage. Der Grundriss hat 2 eigene Schritte, das zweite Szenario 3. Insgesamt: 2 · (2 + 2) + (2 + 3) = 8 + 5 = 13 Schritte. (2 Punkte)

• Zeile 12 (erster Durchlauf: „Wenn sie das Gesuch ab “Gütersloh” mit dem Grund “Mitfahrt gefunden” zurückzieht“): zurueckziehen("Gütersloh", "Mitfahrt gefunden"). Die Platzhalter sind schon ersetzt, bevor Cucumber zuordnet. (1 Punkt)
• Zeile 21: keine Methode passt, weil „ohne Grund“ nicht zu „mit dem Grund {string}“ passt. Der Schritt ist undefined; Cucumber lässt das Szenario scheitern, überspringt die übrigen Schritte und schlägt eine Methode mit @Wenn("sie das Gesuch ab {string} ohne Grund zurückzieht") vor. (1,5 Punkte)
• Zeile 23: zeigtWeiter("mensa", 2). Das Schlüsselwort Aber spielt beim Zuordnen keine Rolle, und offene(s) Gesuch(e) passt durch die optionalen Teile auch zu „offene Gesuche“. (Weil Zeile 21 undefined ist, kommt Cucumber in diesem Szenario allerdings gar nicht bis Zeile 23.) (1,5 Punkte)

1. Systemtest: geprüft wird gegen den Entwurf der Oberfläche (Adresse, Status, Aufbau der Tabelle), nicht gegen eine Anforderung. (1 Punkt)
2. Abnahmetest: Fachseite schreibt mit, der Product Owner entscheidet über die Abnahme. (1 Punkt)
3. Abnahmetest: Prüfgrundlage ist ein Abnahmekriterium, also eine Anforderung. (1 Punkt)

# language: de
@akzeptanz @MON-13d
Funktionalität: Mitfahrgesuche je Monitor
  Als Auszubildende*r mit Auto möchte ich an jedem Monitor die offenen Gesuche
  in seinen Richtungen sehen, damit ich jemanden mitnehmen kann (MON-13d).

  Grundlage:
    Angenommen es ist Montag, der 16.11.2026, 06:00 Uhr

  Szenariogrundriss: AK-MON-13d.1 Jeder Monitor zeigt die Gesuche seiner Richtungen
    Wenn der Monitor "<monitor>" die Gesuche lädt
    Dann zeigt er <gesuche> aus "<orte>"

    Beispiele:
      | monitor     | gesuche          | orte                 |
      | mensa       | 2 offene Gesuche | Gütersloh, Bielefeld |
      | flur-b      | 1 offenes Gesuch | Gütersloh            |
      | parkplatz-c | 1 offenes Gesuch | Bielefeld            |

  Szenario: AK-MON-13d.2 Ein Monitor zeigt auf Wunsch nur die Gesuche eines Orts
    Wenn der Monitor "mensa" die Gesuche für den Ort "Bielefeld" lädt
    Dann zeigt er 1 offenes Gesuch aus "Bielefeld"

  Szenario: AK-MON-13d.3 Ohne passende Gesuche steht ein Satz statt einer leeren Tabelle
    Wenn der Monitor "mensa" die Gesuche für den Ort "Herford" lädt
    Dann zeigt er 0 offene Gesuche
    Und steht dort der Satz "Gerade keine offenen Gesuche."

Bewertung: Sprachangabe und Tag @akzeptanz (1 Punkt), Funktionalität mit Beschreibung der Story (1 Punkt), Grundlage mit der Uhr auf Montag, 16.11.2026 (1 Punkt), Szenariogrundriss mit Platzhaltern und drei Beispielzeilen mit richtigen Erwartungen (3 Punkte), Szenarien für 13d.2 und 13d.3 mit genau einem Wenn (2 Punkte), Namen beginnen mit der Nummer des Kriteriums (1 Punkt).

Die Spalte gesuche enthält Zahl und Wort („1 offenes Gesuch“), damit der Satz grammatisch stimmt. Schreibt man stattdessen Dann zeigt er <anzahl> offene(s) Gesuch(e) aus "<orte>", steht nach dem Ersetzen „offene(s) Gesuch(e)“ wörtlich im Schritt. Optionaler Text ist nur in Cucumber Expressions erlaubt, nicht im Gherkin-Text; der Schritt wäre undefined.

Alle Szenarien der Datei brauchen denselben Ausgangszeitpunkt; die Grundlage nennt ihn einmal, die Szenarien bleiben kurz und zeigen nur, worin sie sich unterscheiden (2 Punkte). Einen eigenen Schritt braucht ein Szenario, dessen Kriterium von einem anderen Zeitpunkt handelt, zum Beispiel „Angenommen, es ist Freitag, 15:00 Uhr“, um zu prüfen, dass Gesuche für Montag schon am Freitagnachmittag erscheinen. Der Schritt im Szenario stellt die Uhr nach der Grundlage noch einmal um (1 Punkt).

package de.dbh.mitfahrlabor.akzeptanztest;

import static org.assertj.core.api.Assertions.assertThat;

import java.util.Arrays;

import de.dbh.mitfahrlabor.guitest.seiten.GesucheSeite;
import io.cucumber.java.de.Dann;
import io.cucumber.java.de.Wenn;

/** Step Definitions zu den Mitfahrgesuchen am Monitor (MON-13d). */
public class GesucheSchritte {

    private final Testwelt welt;

    private GesucheSeite seite;

    public GesucheSchritte(Testwelt welt) {
        this.welt = welt;
    }

    @Wenn("der Monitor {string} die Gesuche lädt")
    public void gesucheLaden(String monitor) {
        seite = GesucheSeite.oeffnen(welt.browser(), welt.basis(), monitor, null);
    }

    @Wenn("der Monitor {string} die Gesuche für den Ort {string} lädt")
    public void gesucheFuerOrtLaden(String monitor, String ort) {
        seite = GesucheSeite.oeffnen(welt.browser(), welt.basis(), monitor, ort);
    }

    @Dann("zeigt er {int} offene(s) Gesuch(e) aus {string}")
    public void zeigtGesucheAus(int anzahl, String orte) {
        assertThat(seite.anzahl()).isEqualTo(anzahl);
        assertThat(seite.orte()).containsExactlyElementsOf(Arrays.asList(orte.split(",\\s*")));
    }

    @Dann("zeigt er {int} offene(s) Gesuch(e)")
    public void zeigtGesuche(int anzahl) {
        assertThat(seite.anzahl()).isEqualTo(anzahl);
        assertThat(seite.orte()).hasSize(anzahl);
    }

    @Dann("steht dort der Satz {string}")
    public void stehtDerSatz(String satz) {
        assertThat(seite.meldungOhneGesuche()).isEqualTo(satz);
    }
}

Bewertung: Konstruktor mit Testwelt (1 Punkt), zwei @Wenn-Methoden mit passenden Cucumber Expressions und Page Object (2 Punkte), {int} und optionaler Text offene(s) Gesuch(e) für Einzahl und Mehrzahl (2 Punkte), Prüfung von Anzahl und Reihenfolge der Orte (2 Punkte), Satz über das Page Object statt eines Locators in der Step Definition (1 Punkt).

Die Seite liegt hier in einem Feld der Step-Definition-Klasse, weil nur diese Klasse sie braucht; Cucumber legt die Klasse für jedes Szenario neu an. Der Schritt „Dann zeigt er 1 offenes Gesuch aus …“ und „zeigt er 0 offene Gesuche“ passen nicht zur gleichen Methode, weil der eine mit aus {string} endet. Mit dem Code aus diesem Artikel und dem Startcode laufen alle fünf Szenarien grün (./gradlew akzeptanzTest -Dcucumber.filter.tags=@MON-13d).

Cucumber vergleicht den ganzen Satz mit dem ganzen Ausdruck, nicht nur den Anfang. „bei den Fahrten {richtung} diese Fahrt:“ und „{int} offene(s) Gesuch(e) aus {string}“ passen nie auf denselben Text (1 Punkt). Mehrdeutig wäre es erst, wenn zwei Ausdrücke denselben Satz vollständig treffen, etwa zeigt er {int} offene(s) Gesuch(e) aus {string} und zeigt er {int} offene Gesuche aus {string} für den Satz „zeigt er 2 offene Gesuche aus …“ (1 Punkt).

Der Spring-Kontext und damit die Bean GesuchService leben für alle Szenarien weiter. Der Hook nachDemSzenario löscht nur neue Zeilen in den Tabellen angebot und hinweis; die Liste im GesuchService setzt er nicht zurück (1 Punkt). Läuft das Szenario zum Zurückziehen vor gesuche.feature, fehlt danach ein Gesuch, und AK-MON-13d.1 meldet zum Beispiel 1 statt 2 Gesuchen an der Mensa. Das Ergebnis hängt von der Reihenfolge der Dateien ab: Der Test ist nicht unabhängig (1 Punkt).

Lösung (2 Punkte, eine reicht): Der GesuchService bekommt eine Methode, die den Startzustand wiederherstellt, und ein @Before-Hook ruft sie auf; oder die Gesuche wandern wie Angebote und Hinweise in die Datenbank (der eigentliche Plan von MON-13), dann räumt der vorhandene Hook auch sie auf; oder das Szenario zum Zurückziehen legt sich sein Gesuch selbst an und zieht nur dieses zurück. Den Kontext für jedes Szenario neu zu starten (@DirtiesContext) wäre richtig, aber sehr langsam.

• MON-15: abnehmbar. Das einzige Kriterium ist durch ein Szenario belegt und erfüllt; zur DoD gibt es keinen Befund. (1 Punkt)
• MON-13d: nicht abnehmbar. AK-MON-13d.3 ist nicht erfüllt, und die DoD verlangt, dass alle Abnahmekriterien als automatisierte Tests grün sind. Der Eintrag wird nicht vorgeführt und geht zurück ins Product Backlog. (2 Punkte)
• MON-13e: nicht abnehmbar. AK-MON-13e.1 ist nicht geprüft, und zwei Punkte der DoD sind verletzt: Merge Request ohne Review, Pipeline nicht vollständig grün (der Kontrast gehört zur Barrierefreiheit der DoD). Dass die Sichtprüfung erfüllt ist, reicht nicht. (2 Punkte)
• MON-07.5: abnehmbar, wenn das Kriterium nur „vollständig auf dem Monitor“ im Querformat verlangt; das Szenario ist grün. Die Beobachtung am hochkant montierten Monitor ist eine neue Erkenntnis aus dem Review, kein Mangel am vereinbarten Kriterium. Eine Begründung, ihn wegen des abgeschnittenen Texts nicht abzunehmen, ist ebenfalls vertretbar, wenn sie sich darauf stützt, dass der Mensa-Monitor zu „auf dem Monitor“ gehört. (1 Punkt)

Velocity Sprint 4 = MON-15 (2) + MON-07.5 (1) = 3 Story Points (bei der anderen Entscheidung zu MON-07.5 sind es 2). (1 Punkt)

Durchschnitt = (10 + 21 + 13 + 3) / 4 = 47 / 4 = 11,75 Story Points (bzw. 46 / 4 = 11,5). (1 Punkt)

Ein Eintrag ist fertig oder nicht fertig; ein Inkrement mit einer leeren Tabelle oder ungeprüftem Kontrast kann nicht ausgeliefert werden. Anteilige Punkte würden die Velocity schönrechnen und die nächste Planung verfälschen. (1 Punkt)

Je sinnvoller, begründeter Folge 1 Punkt, höchstens 4, zum Beispiel:

• MON-13d und MON-13e gehen unverändert mit ihrer Schätzung zurück ins Product Backlog; Thomas Becker ordnet sie neu, voraussichtlich weit oben, weil wenig Arbeit fehlt. Die Schätzung wird nicht nachträglich verkleinert.
• Für die Darstellung am hochkant montierten Monitor entsteht ein neues Abnahmekriterium (zum Beispiel AK-MON-07.6 „… auch auf dem Monitor der Mensa im Hochformat“) oder eine neue Story „Monitore im Hochformat“, die im nächsten Refinement geschätzt wird.
• Im Szenariogrundriss zu den Gesuchen fehlt ein Fall „Monitor ohne Gesuche ohne Ortsfilter“; das Team prüft, ob die leere Tabelle nur mit Ortsfilter auftritt, und ergänzt ein Beispiel.
• Prozess für die Retrospektive: Pipeline-Jobs dürfen für einen Merge nicht übersprungen werden; der Job templates wird als Pflicht-Job eingerichtet (in GitLab: Merge nur bei erfolgreicher Pipeline).
• Prozess: Das fehlende Review durch eine zweite Person fiel erst im Sprint Review auf; sie gehört vor den Merge (Einstellung „Genehmigung erforderlich“ im Merge Request).

Der Wunsch ist verständlich: Der Fehler ist klein, und das Ergebnis soll sichtbar werden (1 Punkt). Dagegen spricht: Die DoD ist eine Vereinbarung des ganzen Scrum Teams; wird sie für einen Eintrag ausgesetzt, verliert sie für alle ihre Wirkung, und die Velocity zeigt Arbeit als fertig, die noch offen ist. Außerdem hat Thomas Becker AK-MON-13d.3 selbst vereinbart; das Szenario ist das vereinbarte Prüfmittel (1 Punkt). Vorschlag: Die Gesuche dürfen im Review als Zwischenstand gezeigt werden, ausdrücklich als „nicht fertig“; MON-13d bleibt im Product Backlog und wird im nächsten Sprint abgeschlossen. Will der Product Owner die Anforderung ändern (leere Tabelle ist akzeptabel), muss er das Kriterium im Refinement ändern, nicht im Review übergehen (1 Punkt). Andere begründete Stellungnahmen sind möglich, wenn sie DoD und Abnahmekriterien berücksichtigen.