Testautomatisierung

« Back to Glossary Index

Kurzdefinition

Testautomatisierung bezeichnet den Einsatz von Software, um Testaktivitäten auszuführen oder zu unterstützen – z. B. Testdesign, Testausführung, Ergebnisprüfung und Testmanagement.

Wozu dient Testautomatisierung?

• Schnelleres Feedback: Automatisierte Tests verkürzen die Rückkopplung, ob eine Änderung etwas „kaputt gemacht“ hat, von Tagen/Wochen auf Sekunden/Minuten.
• Qualität im Delivery-Prozess: In Continuous Integration (CI) werden Code-Änderungen automatisch gebaut und getestet, sobald Commits eingehen – so werden Fehler früher sichtbar.
• Wiederholbarkeit: Regressionstests können zuverlässig und häufig wiederholt werden, ohne dass jedes Mal manuell geklickt/abgeprüft werden muss.

Welche Arten von Tests werden typischerweise automatisiert? (Testpyramide)

Die Testpyramide ist ein verbreitetes Modell, um automatisierte Tests nach Granularität zu strukturieren und ein balanciertes Portfolio aufzubauen.

• Unit-Tests (Basis): Viele, schnelle Tests auf Methoden/Funktionen/Klassenebene.
• Integrations-/Service-Tests (Mitte): Prüfen Zusammenspiel mehrerer Komponenten (z. B. DB, Services).
• End-to-End (E2E)/UI-Tests (Spitze): Prüfen Nutzerflüsse über die Oberfläche/gesamte Kette; sind wertvoll, aber oft langsamer und potenziell anfälliger.

Praxis-Merksatz: „Unten viel, oben wenig“ – je höher (E2E/UI), desto teurer in Laufzeit und Wartung, aber desto näher am echten Nutzerfluss.

Typische Tools (Beispiele)

• Selenium: Tools/Bibliotheken zur Automatisierung von Webbrowsern (WebDriver etc.).
• Cypress: Framework für End-to-End-Tests im Browser, inkl. Schreiben und Ausführen von E2E-Tests.

Beispiele (praktisch & website-tauglich)

1) Unit-Test (Beispiel: Preisberechnung ist stabil)

Ziel: Eine Regel-/Preisfunktion liefert bei definiertem Input immer das korrekte Ergebnis (schnell, robust).

// Beispiel (Pseudo): Preisberechnung für eine Konfiguration
import { berechnePreis } from "./pricing";

test("berechnet Gesamtpreis inkl. Aufpreis korrekt", () => {
  const config = { basis: 1000, optionA: true, optionB: false };
  expect(berechnePreis(config)).toBe(1200); // z. B. +200 für optionA
});
``

Warum automatisieren? Unit-Tests sind typischerweise schnell, liefern früh Feedback und bilden die Basis der Testpyramide.

2) API-/Integrationstest (Beispiel: Angebot wird erzeugt und validiert)

Ziel: Ein Service liefert konsistente Antworten und validiert Regeln über die „Schnittstelle“ (ohne UI).

# Beispiel (Pseudo) mit pytest-Style: API erzeugt ein Angebot
def test_offer_creation_returns_valid_quote(api_client):
    payload = {
        "productId": "P-123",
        "configuration": {"size": "L", "color": "black"},
    }
    response = api_client.post("/offers", json=payload)
    assert response.status_code == 201
    data = response.json()
    assert data["status"] == "CREATED"
    assert data["totalPrice"] > 0

Einordnung: Solche Tests liegen in der Mitte der Pyramide (Service/Integration) und sind oft stabiler als UI-getriebene E2E-Tests.

3) UI/E2E-Test mit Cypress (Beispiel: Nutzer kann Checkout abschließen)

Ziel: Ein kompletter Nutzerfluss wird im Browser durchgespielt (vom Öffnen der Seite bis zur Bestätigung).

// Cypress (vereinfachtes Beispiel)
describe("Checkout", () => {
  it("schließt eine Bestellung erfolgreich ab", () => {
    cy.visit("/shop");
    cy.contains("Produkt konfigurieren").click();
    cy.get("[data-test=size]").select("L");
    cy.get("[data-test=add-to-cart]").click();
    cy.get("[data-test=checkout]").click();
    cy.contains("Bestellung erfolgreich").should("be.visible");
  });
});

Hinweis: E2E-Tests liefern starke Nutzer-Absicherung, sind aber häufig langsamer und können anfälliger sein als kleinere Tests.

4) BDD/Gherkin-Akzeptanztest (Beispiel aus Konfigurator-/Angebotsdomäne)

Ziel: Fachlich lesbare Akzeptanzkriterien, die später automatisiert werden können. (BDD passt besonders gut, wenn Business & Tech ein gemeinsames Verständnis brauchen.)

Feature: Angebotskonfiguration

  Scenario: Regelkonforme Konfiguration erzeugt ein Angebot
    Given der Nutzer hat ein Produkt mit Optionen konfiguriert
    When alle ausgewählten Optionen gemäß Regelwerk kombinierbar sind
    Then wird ein gültiges Angebot erzeugt
    And der Gesamtpreis ist berechnet
    And die Konfiguration ist als "fertig" markiert

Best Practices

• Automatisiere zuerst das, was häufig wiederholt wird (Regression/Smoke), und halte die Tests deterministisch.
• Nutze die Testpyramide als Leitplanke: viele Unit-, einige Integrations-, wenige E2E-Tests.
• Binde Tests in CI ein, damit jeder Commit/PR automatisch geprüft wird.
• E2E bewusst dosieren: Sie sind wichtig für Nutzerflüsse, aber tendenziell langsamer und wartungsintensiver.

« Back to Glossary Index