Die Grundidee:

• Fachliche Anforderungen, also Wünsche, Erwartungen oder Vorgaben des Kunden, werden zunächst in klaren Szenarien beschrieben.

  Beispiel: 

  • „Ein registrierter Nutzer kann sich erfolgreich einloggen.“

  • „Ein Kunde bekommt eine Bestellbestätigung per E-Mail.“

• Diese Szenarien schaffen später die Grundlage für das automatisierte Testen.

• Im Ergebnis wird ein gemeinsames Verständnis zwischen Kunden, Entwicklung, Testern und QA aufgebaut

Wozu brauchen wir Cucumber?

• Die „Gap“ zwischen Business und Technik schließen: Auch Personen ohne IT-Hintergrund können Szenarien nachvollziehen und sogar mitgestalten.

• Transparenz: Jede Anforderungen kann in einen automatisierten Test umgesetzt werden, wenn sich die Anforderungen ändern, kann auch das Szenario geändert werden

• Dokumentation: Da die Testszenarien für jedermann verständlich sind, dienen sie als auch als lebende Dokumentationsgrundlage.

• Automatisierung: Reduziert manuelles Testarbeit und erhöht die Zuverlässigkeit.

Ablauf eines Cucumber-Tests

Aufbau von Gherkin-Szenarien

Cucumber verwendet die Gherkin-Syntax, die aus Schlüsselwörtern besteht:

• Feature – beschreibt die Funktionalität.
• Scenario – beschreibt einen konkreten Anwendungsfall.
• Given – Ausgangsbedingung.
• When – die Aktion, die durchgeführt wird.
• Then – das erwartete Ergebnis.
• (Optional: And, But – zur besseren Lesbarkeit)

Beispiel: Login-Funktion

Feature: Login
  In order to access my account
  As a registered user
  I want to be able to log in successfully

  Scenario: Successful login with valid credentials
    Given I am on the login page (Hier also die Ausgangsbedingung)
    When I enter a valid username and password (Aktionen)
    And I click on the login button (Aktionen)
    Then I should see the dashboard (Erwartetes Ergebnis)

Step Definitions

Die Szenarien in Gherkin schaffen uns eine Grundlage für die Testautomatisierung und wir arbeiten mit einer Sprache, die auch für Fachkräfte ohne IT-Kenntnisse verständlich ist. Damit Cucumber die Aktionen jedoch auch ausführen kann, braucht es sogenannte Step Definitions, die in einer Programmiersprache implementiert werden.

Da ich fast ausschließlich mit Javascript arbeite, möchte ich nachfolgend ein Beispiel mit WebdriverIO vorstellen. Wir überführen also die Ausgangsbedingung, die Aktionen und das erwartete Ergebnis von oben in JS-Code.

Beispiel in JavaScript (WebdriverIO + Cucumber):

const { Given, When, Then } = require('@cucumber/cucumber');
const assert = require('assert');

Given('I am on the login page', async () => {
  await browser.url('/login');
});

When('I enter a valid username and password', async () => {
  await $('#username').setValue('testuser');
  await $('#password').setValue('securePass123');
});

When('I click on the login button', async () => {
  await $('#login-button').click();
});

Then('I should see the dashboard', async () => {
  const dashboard = await $('#dashboard');
  assert(await dashboard.isDisplayed());
});

Pluspunkte von Cucumber

• Menschenlesbare Sprache → sowohl Kunden, Fachkräfte als auch Entwickler und Tester verstehen die Tests.
• Aktives Dokumentieren → Anforderungen und Tests in einem Artefakt.
• Die Zusammenarbeit im Team wird gestärkt
• Unterstützung durch viele Tools und Frameworks.

Hier kommt Cucumber zum Einsatz

• Webapplikationen testen (z. B. mit Selenium oder WebdriverIO).
• REST-APIs prüfen (z. B. mit HTTP-Requests und JSON-Validierung).
• Mobile Apps testen (z. B. mit Appium).

Mögliche Nachteile

• Kann Overhead erzeugen, wenn Szenarien zu detailliert werden.
• Disziplin im Team notwendig: gute Szenario-Qualität ist entscheidend.
• Für rein technische Tests manchmal „zu groß“ – Unit-Tests sind dort effizienter.

So kann’s gehen

1. Schreibe Szenarien aus Business-Sicht. Zunächst sollte das Verhalten der Anwendung betrachtet werden, und noch nicht über die technische Implementierung nachgedacht werden.
2. Die Szenarien kurz und präzise formulieren, wie oben in dem Beispiel.
3. Wiederverwendbare Step Definitions bauen und auslagern. Heißt, dass alle Step Definitionen einmal zentral gehalten werden, z.B. könnten alle Schritte für das Login in eine loginSteps.js geschrieben werden.
4. Enger Austausch zwischen Fachabteilung, Entwicklern und QA. Im obigen Beispiel sollte die Fachabteilung definieren, was man unter einem erfolgreichen Login versteht. Die Programmierer kümmern sich um die technische Umsetzung und QA’s denken unter anderem darüber nach, welche Edge-Cases abgedeckt werden müssen.
5. Nicht alles mit Cucumber testen, sondern nur fachlich relevante Flows.

Fazit

Cucumber ist ein starkes Tool, um fachliche Anforderungen aus dem Business mit der Testautomatisierung zu verbinden. Es schafft eine gemeinsame Sprache im Team und unterstützt eine saubere, nachvollziehbare Qualitätssicherung.

Wer Cucumber sinnvoll einsetzt, profitiert von einer besseren Zusammenarbeit, einer lebenden Dokumentation und einer stabileren Software.

Weiterführende Informationen

Wenn du mehr über Cucumber erfahren willst, lege ich dir die offizielle Website des Tools ans Herz: https://cucumber.io/