Was ist Pre-testing?

Definition von Pre-Testing

Pre-Testing (auch Vortest, Vorprüfung oder Smoke Test genannt) bezeichnet eine frühe Phase im Softwaretestprozess, die vor den eigentlichen funktionalen, integrativen und systemweiten Tests stattfindet. Ziel des Pre-Testings ist es, die grundlegende Funktionsfähigkeit einer Anwendung oder eines Builds zu verifizieren und sicherzustellen, dass die Software stabil genug ist, um weitergehende Tests durchzuführen. Pre-Testing fungiert als Qualitäts-Gate: Besteht die Software die Vorprüfung nicht, werden tiefgreifendere Tests erst gar nicht gestartet — dies spart Zeit und Ressourcen.

Der Begriff wird in der Praxis häufig synonym mit „Smoke Testing” oder „Build Verification Testing (BVT)” verwendet. Die Metapher des „Smoke Test” stammt aus der Elektrotechnik: Wenn ein Gerät nach dem Einschalten nicht raucht, besteht es den grundlegenden Funktionstest.

Bedeutung des Pre-Testings im Software-Lebenszyklus

Pre-Testing nimmt eine strategisch wichtige Position im Software-Lebenszyklus ein, da es als erste Qualitätskontrolle nach einem neuen Build oder einer Codeänderung fungiert. In modernen CI/CD-Pipelines wird Pre-Testing automatisch nach jedem Build ausgeführt — ein fehlgeschlagener Smoke Test blockiert die weitere Pipeline und verhindert, dass instabile Builds in nachfolgende Testphasen oder gar in Staging-Umgebungen gelangen.

Die Bedeutung des Pre-Testings lässt sich anhand mehrerer Aspekte verdeutlichen:

Frühzeitige Fehlererkennung. Fundamentale Probleme — wie ein Absturz beim Anwendungsstart, ein fehlerhafter Datenbankzugriff oder eine nicht erreichbare API — werden innerhalb von Minuten nach dem Build erkannt, nicht erst nach stundenlangen funktionalen Tests.

Kosteneinsparung. Laut einer Studie des Systems Sciences Institute bei IBM steigt der Aufwand zur Fehlerbehebung exponentiell mit jeder Phase im Entwicklungszyklus. Ein in der Pre-Testing-Phase erkannter Fehler kostet einen Bruchteil eines Fehlers, der erst bei Integrations- oder Akzeptanztests auffällt.

Stabilität des Testprozesses. Wenn umfangreiche Testsuiten auf einem instabilen Build ausgeführt werden, produzieren sie massenweise falsche Fehlermeldungen (False Positives), die das Testerteam verwirren und wertvolle Analysezeit verschwenden. Pre-Testing stellt sicher, dass nur stabile Builds weitergetestet werden.

Pipeline-Effizienz. In CI/CD-Umgebungen, in denen täglich dutzende oder hunderte Builds erstellt werden, ist Pre-Testing der effizienteste Mechanismus, um instabile Builds sofort zu identifizieren und die Pipeline-Ressourcen für sinnvolle Tests zu reservieren.

Kernziele und Nutzen des Pre-Testings

Verifikation der Grundfunktionalität

Pre-Testing prüft die absolut grundlegenden Funktionen einer Anwendung — das Minimum, das funktionieren muss, damit die Software überhaupt sinnvoll getestet werden kann:

• Anwendungsstart: Die Applikation startet fehlerfrei und erreicht den betriebsbereiten Zustand.
• Konnektivität: Die Verbindung zu Datenbanken, externen APIs, Message Queues und anderen Backend-Diensten ist hergestellt.
• Authentifizierung: Der Login-Prozess funktioniert mit gültigen Anmeldedaten.
• Kernnavigation: Die Hauptnavigationspfade der Anwendung sind erreichbar und laden korrekt.
• Grundlegende CRUD-Operationen: Erstellen, Lesen, Aktualisieren und Löschen von Kerndatenobjekten funktioniert.

Identifikation von Build-Problemen

Pre-Testing erkennt typische Build-bezogene Probleme:

• Fehlende oder inkompatible Abhängigkeiten (Dependencies)
• Fehlerhafte Konfigurationen (Umgebungsvariablen, Connection Strings)
• Datenbankmigrationen, die nicht korrekt ausgeführt wurden
• Fehlende oder beschädigte statische Ressourcen (CSS, JavaScript, Bilder)
• Inkompatible API-Versionen zwischen Frontend und Backend

Qualitäts-Gate für die Pipeline

Pre-Testing dient als automatisches Gate in der CI/CD-Pipeline:

• Bestanden: Der Build wird für weitergehende Tests freigegeben (Funktions-, Integrations-, Performancetests).
• Nicht bestanden: Der Build wird blockiert, das Entwicklungsteam wird benachrichtigt, und die Fehlerbehebung wird priorisiert.

Der Pre-Testing-Prozess im Detail

Schritt 1: Definition des Testumfangs

Das Team definiert die kritischen Pfade und Funktionen, die im Pre-Testing abgedeckt werden müssen. Diese Liste sollte bewusst kurz gehalten werden — typischerweise 20-50 Testfälle, die in 5-15 Minuten durchlaufen werden können. Die Auswahl basiert auf:

• Geschäftskritikalität: Welche Funktionen sind für den Kernbetrieb unverzichtbar?
• Häufigste Fehlerquellen: Welche Bereiche sind erfahrungsgemäß am anfälligsten für Build-Probleme?
• Benutzerperspektive: Welche grundlegenden Workflows müssen aus Anwendersicht funktionieren?

Schritt 2: Vorbereitung der Testumgebung

Die Testumgebung muss konsistent und reproduzierbar sein. In modernen Entwicklungsumgebungen werden hierfür:

• Docker-Container: Definierte, reproduzierbare Umgebungen für die Anwendung und ihre Abhängigkeiten.
• Testdatenbanken: Frische Datenbankinstanzen mit definierten Testdaten (Seed Data), die vor jedem Pre-Test zurückgesetzt werden.
• Mock-Services: Externe Abhängigkeiten werden durch Mocks oder Stubs ersetzt, um die Unabhängigkeit des Pre-Tests sicherzustellen.

Schritt 3: Durchführung der Vortests

Die eigentliche Testdurchführung erfolgt idealerweise vollständig automatisiert:

• Automatisierte Testskripte prüfen die definierten Kernfunktionen.
• Jeder Testfall hat eine maximale Ausführungszeit (Timeout), um hängende Tests zu erkennen.
• Die Ergebnisse werden strukturiert protokolliert (Pass/Fail pro Testfall, Screenshots bei Fehlern, Log-Dateien).

Schritt 4: Ergebnisanalyse und Entscheidung

Nach Abschluss der Vortests werden die Ergebnisse analysiert:

• Alle Tests bestanden: Der Build wird freigegeben. Die Pipeline fährt mit der nächsten Phase fort.
• Kritische Tests fehlgeschlagen: Der Build wird blockiert. Das Team erhält eine automatische Benachrichtigung mit den Fehlerdetails.
• Nicht-kritische Tests fehlgeschlagen: Je nach Teststrategie kann der Build mit Einschränkungen freigegeben werden — die fehlgeschlagenen Tests werden als Known Issues dokumentiert.

Schritt 5: Feedback-Schleife

Die Ergebnisse des Pre-Testings werden an das Entwicklungsteam kommuniziert. Bei fehlgeschlagenen Tests stehen folgende Informationen bereit:

• Welcher Testfall ist fehlgeschlagen?
• Welche Fehlermeldung wurde produziert?
• Screenshots und Log-Dateien des Fehlerzeitpunkts
• Welcher Commit hat den Build ausgelöst? (Traceability)

Pre-Testing in CI/CD-Pipelines

In modernen DevOps-Umgebungen ist Pre-Testing ein integraler Bestandteil der CI/CD-Pipeline. Ein typischer Ablauf:

1. Commit: Ein Entwickler pushed Code in das Repository.
2. Build: Die CI-Pipeline kompiliert die Anwendung und erstellt ein Artefakt (Docker-Image, JAR, etc.).
3. Pre-Test/Smoke Test: Das Artefakt wird in einer temporären Umgebung deployed, und die Vortests werden ausgeführt.
4. Gate-Entscheidung: Bei Erfolg wird die Pipeline fortgesetzt; bei Misserfolg wird sie gestoppt.
5. Weiterführende Tests: Funktionale Tests, Integrationstests, Performancetests.
6. Deployment: Bereitstellung auf Staging- oder Produktionsumgebung.

Tools für die Pipeline-Integration:

• Jenkins: Pipeline-Stages für Build, Smoke Test und Gate mit Groovy-Skripten.
• GitLab CI/CD: YAML-basierte Pipeline-Definition mit Stage-Dependencies und Manual Gates.
• GitHub Actions: Workflow-Steps mit Conditions für Pass/Fail-Entscheidungen.
• Azure DevOps Pipelines: Multi-Stage-Pipelines mit Gate-Bedingungen und Genehmigungsworkflows.

Werkzeuge für das Pre-Testing

Test-Automatisierungsframeworks

• Selenium: Browserbasierte Testautomatisierung für Web-Anwendungen. Ideal für Pre-Tests, die UI-Interaktionen prüfen.
• Cypress: Modernes JavaScript-basiertes Framework mit schneller Ausführung und integriertem Debugging — gut geeignet für schnelle Smoke Tests.
• Playwright: Microsofts Cross-Browser-Testframework mit Unterstützung für Chromium, Firefox und WebKit.
• Appium: Für Pre-Testing von mobilen Anwendungen (iOS und Android).
• REST Assured / Supertest: Für API-basierte Pre-Tests, die Backend-Endpunkte und -Konnektivität prüfen.

Testmanagement

• TestRail: Verwaltung von Pre-Test-Suiten, Planung und Nachverfolgung der Ergebnisse.
• Zephyr (Jira-Plugin): Integration von Testfällen direkt in Jira für nahtlose Traceability.
• Allure Report: Open-Source-Reporting-Framework für ansprechende und detaillierte Testergebnis-Berichte.

Monitoring und Health Checks

• Healthcheck-Endpunkte: Standardisierte /health oder /readiness-Endpunkte in der Anwendung, die den Status von Datenbankverbindungen, externen Diensten und internen Komponenten prüfen.
• Kubernetes Readiness Probes: In containerisierten Umgebungen prüfen Readiness Probes automatisch, ob ein Pod bereit ist, Anfragen zu empfangen.

Pre-Testing vs. andere Testarten

Aspekt	Pre-Testing / Smoke Test	Regressionstest	Funktionaler Test
Zeitpunkt	Sofort nach Build	Vor Release	Während Entwicklung
Umfang	Minimal (20-50 Fälle)	Umfassend (Hunderte-Tausende)	Feature-spezifisch
Dauer	5-15 Minuten	Stunden	Minuten-Stunden
Tiefe	Oberflächlich (happy path)	Tief (inkl. Edge Cases)	Mittel-tief
Ziel	Build-Stabilität prüfen	Keine Regression	Funktionale Korrektheit
Automatisierung	Immer automatisiert	Meist automatisiert	Manuell oder automatisiert

Herausforderungen beim Pre-Testing

• Auswahl der richtigen Testfälle: Die Kunst liegt darin, die richtige Balance zwischen Abdeckung und Geschwindigkeit zu finden. Zu wenige Testfälle lassen kritische Fehler durch; zu viele verzögern die Pipeline unnötig.
• Testumgebungs-Stabilität: Instabile Testumgebungen (flaky Tests) produzieren falsche Fehlermeldungen und untergraben das Vertrauen in den Pre-Testing-Prozess.
• Testdaten-Management: Die Bereitstellung konsistenter, repräsentativer Testdaten für jeden Testlauf erfordert sorgfältige Planung.
• Abhängigkeiten von externen Diensten: Wenn Pre-Tests von externen APIs oder Diensten abhängen, die nicht verfügbar sind, können sie fehlschlagen, obwohl die eigene Anwendung fehlerfrei ist. Mocks und Service-Virtualisierung lösen dieses Problem.
• Wartung der Testskripte: Pre-Test-Skripte müssen bei Änderungen an der Anwendung aktualisiert werden, um relevant und korrekt zu bleiben.

Best Practices für effektives Pre-Testing

• Kurz und fokussiert halten: Pre-Tests sollten in unter 15 Minuten abgeschlossen sein. Alles, was länger dauert, gehört in eine spätere Testphase.
• 100% automatisieren: Pre-Testing muss vollständig automatisiert sein — manuelle Vortests sind in CI/CD-Umgebungen nicht praktikabel.
• Kritische Pfade priorisieren: Konzentrieren Sie sich auf die absolut geschäftskritischen Funktionen — Login, Kernworkflows, Datenpersistenz, externe Konnektivität.
• Unabhängigkeit sicherstellen: Pre-Tests sollten nicht von externen Diensten, anderen Teams oder manuellen Schritten abhängen. Verwenden Sie Mocks und Testcontainers.
• Flaky Tests sofort beheben: Ein Pre-Test, der manchmal besteht und manchmal fehlschlägt, ist wertlos und schadet dem Vertrauen in den Prozess. Beheben oder entfernen Sie instabile Tests sofort.
• Ergebnisse sichtbar machen: Integrieren Sie Pre-Test-Ergebnisse in die Team-Dashboards (Slack-Benachrichtigungen, Build-Status-Badges, Allure-Reports).
• Regelmäßig überprüfen und anpassen: Überprüfen Sie vierteljährlich, ob die Pre-Test-Suite noch die richtigen Funktionen abdeckt, und passen Sie sie an Veränderungen der Anwendung an.
• Testdaten deterministisch halten: Verwenden Sie definierte Seed-Daten und setzen Sie die Testdatenbank vor jedem Lauf zurück, um reproduzierbare Ergebnisse zu gewährleisten.