Wann lohnt sich Testautomatisierung? Selenium, Playwright und Appium im Vergleich

„Sollen wir Testautomatisierung einführen?“ gehört zu den Fragen, die kleine Teams und Product Owner am häufigsten stellen. Die Antwort lautet weder „unbedingt“ noch „lohnt sich nicht“. An der richtigen Stelle spart Automatisierung bei jedem Release Stunden; an der falschen Stelle wird sie zu einem Berg ungepflegter Tests, die ständig rot sind und die irgendwann niemand mehr beachtet. In diesem Artikel erkläre ich praxisnah, was manuelle und automatisierte Tests abdecken, wann sich Automatisierung rechnet, wie Sie zwischen Selenium, Playwright und Appium wählen und wo Sie anfangen sollten.

Was decken manuelle und automatisierte Tests ab?

Manuelles Testen bedeutet, dass ein Mensch die Anwendung tatsächlich benutzt und prüft. Das menschliche Auge erkennt merkwürdige Designdetails, verwirrende Texte und Abläufe, die „funktionieren, aber keinen Sinn ergeben“. Für exploratives Testen, Usability-Bewertungen und die erste Prüfung neuer Funktionen ist manuelles Testen unverzichtbar.

Automatisiertes Testen bedeutet, dass Code vordefinierte Schritte immer wieder auf genau dieselbe Weise ausführt. Er wird nicht müde, überspringt keinen Schritt und kann Dutzende Szenarien in wenigen Minuten durchlaufen. Er prüft aber nur das, was man ihm vorgibt: Neue Fehler „bemerkt“ er nicht, er stellt fest, ob bekanntes Verhalten noch funktioniert.

Kurz gesagt: Beide sind keine Konkurrenten, sondern ergänzen sich. Die Automatisierung übernimmt wiederkehrende Prüfungen, damit Menschen ihre Zeit dort einsetzen können, wo wirklich Nachdenken gefragt ist.

Wann rechnet sich Automatisierung?

Jeder Test ist eine Investition: Das Schreiben kostet Zeit, und die Pflege bei Änderungen der Anwendung ebenfalls. Diese Investition zahlt sich in der Regel aus, wenn:

• Sie denselben Ablauf häufig testen. Wenn Sie bei jedem Release Login, Registrierung, Warenkorb und Checkout von Hand durchklicken, sind genau diese Schritte die ersten Kandidaten.
• Der Ausfall bestimmter Abläufe teuer ist. Ein Warenkorb, der keine Zahlungen annimmt, oder ein defektes Passwort-Zurücksetzen bedeutet direkt verlorenes Geld und verlorene Kunden.
• Sie häufig releasen. Ein Team, das mehrmals pro Woche live geht, kann nicht jedes Mal eine lange manuelle Checkliste abarbeiten.
• Sie mehrere Browser oder Geräte unterstützen. Dasselbe Szenario von Hand in Chrome, Firefox und Safari zu prüfen, wird schnell mühsam.
• Das Produkt eine gewisse Reife erreicht hat. In einem frühen Prototyp, dessen Oberfläche sich wöchentlich ändert, brechen Tests ständig; sobald die Kernabläufe stehen, wird Automatisierung deutlich effizienter.

Umgekehrt ist bei einer einmaligen Kampagnenseite, einem sehr frühen MVP oder einer visuellen Designprüfung manuelles Testen meist sinnvoller.

Werkzeugwahl: Selenium, Playwright, Appium

Selenium

Selenium ist das etablierteste Werkzeug für Browserautomatisierung und die Grundlage des W3C-WebDriver-Standards. Es unterstützt viele Sprachen, darunter Java, Python, C#, JavaScript und Ruby, und mit Selenium Grid lassen sich Tests parallel auf mehreren Rechnern ausführen. Arbeitet Ihr Team bereits mit Java oder C# oder haben Sie eine bestehende Testinfrastruktur im Unternehmen, ist Selenium nach wie vor eine starke Wahl. Der Nachteil: Wartelogik und Reporting müssen Sie oft selbst aufbauen.

Playwright

Playwright ist ein neueres Werkzeug von Microsoft. Es steuert die Engines Chromium, Firefox und WebKit über eine einzige API und unterstützt TypeScript/JavaScript, Python, Java und .NET. Der größte Vorteil ist das automatische Warten: Playwright wartet selbst, bis ein Element wirklich bedienbar ist, was instabile (flaky) Tests deutlich reduziert. Ein eingebauter Test-Runner, parallele Ausführung, Screenshots, Videos und ein Trace Viewer zur schrittweisen Analyse sind direkt enthalten. Für ein Webprojekt, das bei null startet, empfehle ich in den meisten Fällen Playwright.

Appium

Haben Sie statt einer Website eine native Android- oder iOS-App, kommt Appium ins Spiel. Appium nutzt ebenfalls das WebDriver-Protokoll und führt Tests auf echten Geräten und Emulatoren aus, über Treiber wie UiAutomator2 für Android und XCUITest für iOS. Die Einrichtung ist aufwendiger als bei Web-Werkzeugen, und mobile Tests sind naturgemäß langsamer. Deshalb sollten Sie die Anzahl der Szenarien auf Mobilgeräten besonders sorgfältig wählen.

Ein kleines Playwright-Beispiel

Der folgende Test prüft, ob sich ein Nutzer anmelden und das Dashboard sehen kann. Auch in echten Projekten sind meine ersten Tests meist genau so schlicht:

// tests/login.spec.ts
import { test, expect } from '@playwright/test';

test('user can log in and see the dashboard', async ({ page }) => {
  await page.goto('https://example.com/login');

  await page.getByLabel('Email').fill('demo@example.com');
  await page.getByLabel('Password').fill('correct-password');
  await page.getByRole('button', { name: 'Sign in' }).click();

  // Playwright waits automatically until these become true (or times out)
  await expect(page).toHaveURL(/dashboard/);
  await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
});

// Run: npx playwright test

Beachten Sie, dass statt CSS-Klassen Selektoren wie getByRole und getByLabel verwendet werden, die sich an dem orientieren, was der Nutzer sieht. So brechen Tests bei Designänderungen seltener.

CI-Integration

Ihren eigentlichen Wert zeigen Tests erst, wenn sie automatisch laufen, ohne dass jemand daran denken muss. Sie fügen in einem CI-System wie GitHub Actions oder GitLab CI einen Schritt hinzu, der die Tests bei jedem Pull Request oder jedem Push auf den Hauptbranch ausführt; schlägt ein Test fehl, wird das Mergen blockiert, und Bericht, Screenshots oder Trace-Dateien werden als Artefakte gespeichert. Playwright bietet dafür einen fertigen CI-Leitfaden mit Beispielkonfigurationen, und die erste Einrichtung dauert in den meisten Projekten weniger als eine Stunde.

Häufige Fehler

• Alles testen wollen. Hunderte End-to-End-Tests ergeben eine langsame, schwer wartbare Suite. Gesünder ist es, kritische Abläufe end-to-end und Details mit Unit- und API-Tests abzudecken.
• Instabile Tests ignorieren. Ein Test, der mal besteht und mal scheitert, zerstört das Vertrauen des Teams in die Ergebnisse. Nutzen Sie bedingungsbasierte Wartezeiten statt fester sleep-Aufrufe und beheben Sie instabile Tests sofort, oder deaktivieren Sie sie vorübergehend und dokumentieren Sie das.
• Fragile Selektoren. Lange XPaths oder automatisch generierte CSS-Klassen brechen bei der kleinsten Designänderung. Bevorzugen Sie barrierefreie Rollen, Labels oder eigene data-testid-Attribute.
• Voneinander abhängige Tests. Jeder Test sollte seine eigenen Daten vorbereiten und allein lauffähig sein; sonst bricht alles zusammen, sobald sich die Reihenfolge ändert.
• Wartungskosten unterschätzen. Testcode ist Code: Er muss lesbar bleiben und mit der Anwendung weiterentwickelt werden.

Wie fangen Sie an?

1. Listen Sie die drei bis fünf kritischen Abläufe auf, deren Ausfall Sie am meisten kosten würde: meist Login, Registrierung, Zahlung und die Kernfunktion.
2. Beschreiben Sie diese Abläufe zunächst Schritt für Schritt in einfachem Text; das ist zugleich Ihre manuelle Testcheckliste.
3. Automatisieren Sie diese Szenarien mit Playwright für das Web oder Appium für Mobile.
4. Binden Sie die Tests in die CI ein und lassen Sie sie bei jeder Änderung laufen.
5. Erweitern Sie die Suite schrittweise, wenn echte Fehler gefunden oder neue kritische Funktionen hinzukommen.

Eine kleine, aber verlässliche Testsuite ist immer mehr wert als eine große, der niemand vertraut.

Fazit

Testautomatisierung ist kein Selbstzweck, sondern ein Werkzeug, mit dem Sie entspannt releasen können. Mit den richtigen Abläufen und dem richtigen Werkzeug rechnet sie sich schnell, auch für kleine Teams. Wenn Sie gemeinsam herausfinden möchten, welche Szenarien in Ihrem Projekt automatisiert werden sollten, oder Ihre bestehenden Tests zuverlässiger machen wollen, nehmen Sie gern Kontakt mit mir auf.