Die meisten Testfälle scheitern, bevor sie auch nur einen einzigen Fehler aufdecken. Sie sind als vage Checklisten verfasst, lassen Vorbedingungen außer Acht, bündeln mehrere Aktionen in einem Schritt oder beschreiben erwartete Ergebnisse so vage, dass zwei Tester, die denselben Fall lesen, sich nicht darüber einig wären, was „bestanden“ bedeutet. Das Ergebnis: Fehler schlüpfen durch die Maschen, Testläufe lassen sich nicht reproduzieren, und die Qualitätssicherung wird zum Engpass statt zum Sicherheitsnetz.
Beim Verfassen eines guten Testfalls geht es weniger um Testfähigkeiten als vielmehr um das Design der Überprüfung. In der Finanzbranche wird dies als „Maker-Checker-Prozess“ bezeichnet. Im Bereich der nuklearen Kommandostruktur spricht man von der „Zwei-Personen-Regel“. Das Prinzip ist dasselbe: Kritische Aufgaben sollten niemals von einer einzigen, ungeprüften Aktion abhängen. Ein gut geschriebener Testfall bringt dieselbe Strenge in die Software ein. Er trennt das, was Sie erwarten, von dem, was Sie beobachten, sodass die Diskrepanz zwischen beiden nicht mehr zu übersehen ist.
Wir zeigen Ihnen, wie Sie Testfälle verfassen, warum sie wichtig sind und wie Sie die Qualität Ihrer Testfälle im Laufe der Zeit verbessern können.
TL;DR
Ein Testfall definiert die genauen Schritte, Eingaben und erwarteten Ergebnisse, die erforderlich sind, um zu überprüfen, ob ein Feature korrekt funktioniert. Jeder Testfall benötigt eine eindeutige ID, Vorbedingungen und erwartete Ergebnisse, die so formuliert sind, dass das Ergebnis überprüft werden kann. Dieser Leitfaden behandelt den siebenstufigen Erstellungsprozess, drei Beispiele und wie man eine Testsuite auch bei Produktänderungen zuverlässig hält.
Was sind Testfälle?
Ein Testfall ist ein strukturiertes Dokument, das die genauen Schritte, Eingaben, Voraussetzungen und erwarteten Ergebnisse definiert, die erforderlich sind, um zu überprüfen, ob sich eine bestimmte Software korrekt verhält. Es handelt sich dabei weder um einen Testplan (der die Teststrategie umreißt) noch um ein Testskript (ein automatisierter Code, der die Schritte programmgesteuert ausführt). Ein Testfall ist die Spezifikation, auf der beide aufbauen.
Beispiel: Sie testen die Anmeldefunktion einer Webanwendung. Ein Testfall für dieses Feature würde die folgenden Elemente definieren:
- Aktionen, die die von einem Benutzer ausgeführten Schritte und die erwarteten Systemreaktionen beschreiben
- Bedingungen, die die Regeln definieren, die erfüllt sein müssen, damit das System mit jedem Schritt fortfahren kann
- Geben Sie Eingabedaten mit Beispielwerten ein, um verschiedene Ergebnisse zu testen und sowohl Erfolge als auch Fehlerszenarien zu überprüfen
Manuelle vs. automatisierte Testfälle im Vergleich
KI ist mittlerweile Teil der meisten Test-Workflows. 76,8 % der Testexperten setzen KI in der Qualitätssicherung ein, wobei laut dem „State of Testing Report 2026“ der Bereich der Erstellung von Testfällen (69,6 %) und der Bereich der Skriptpflege (59,6 %) die beiden häufigsten Anwendungsbereiche sind. Bei automatisierten Testfällen zeigt sich dieser Wandel am deutlichsten, daher lohnt es sich zu wissen, wie sie sich von manuellen Testfällen unterscheiden.
| Parameter | Manuelle Testfälle | Automatisierte Testfälle |
|---|---|---|
| Ausführung | Durchgeführt von einem menschlichen Tester, der eine Reihe dokumentierter Schritte befolgt | Ausgeführt durch Software-Tools, Skripte oder KI-Agenten |
| Geschwindigkeit | Langsam und zeitaufwendig, da Menschen Daten manuell eingeben und Ergebnisse überprüfen müssen | Kann Hunderte von Testfällen gleichzeitig ausführen |
| Wiederholbarkeit | Anfällig für menschliche Fehler und uneinheitliche Interpretation der Schritte | Hohe Wiederholbarkeit und Konsistenz bei gut gepflegten Testskripten |
| CI/CD-Integration | Schwierig in schnelllebige Delivery-Pipelines zu integrieren aufgrund personeller Engpässe | Lässt sich direkt in CI/CD-Pipelines integrieren, um bei jedem Build Tests auszuführen |
| Wartung | Erfordert manuelle Aktualisierungen der Dokumente, sobald sich die Anforderungen ändern | Erfordert technische Wartung zur Aktualisierung von Skripten, wenn sich die Benutzeroberfläche oder die Logik ändert |
| Ideal für | Explorative Tests | Wiederholungstests und Regressionstests |
Warum gut geschriebene Testfälle wichtig sind
Sie erkennen Regressionen, bevor Benutzer Tickets einreichen. Jede Codeänderung birgt das Risiko, dass etwas, das bereits funktioniert, nicht mehr funktioniert. Ein gut geschriebener Testfall wird zu einem festen Kontrollpunkt, der nach jedem Deployment ausgeführt wird. Wenn ein Entwickler ein Jahr später Ihren Anmeldecode umgestaltet und dabei versehentlich die Verwaltung der Sitzungen beeinträchtigt, ist es dieser Testfall, der dies in der Phase der Staging-Umgebung aufdeckt.
Machen Sie „bestanden“ oder „nicht bestanden“ zu einer Tatsache, nicht zu einer Meinung. Vage erwartete Ergebnisse wie „das System reagiert angemessen“ zwingen jeden Tester dazu, zu interpretieren, was „angemessen“ bedeutet. Zwei Tester führen denselben Testfall aus, einer wertet ihn als bestanden, der andere meldet einen Fehler – und schon ist das Team damit beschäftigt, die Meinungsverschiedenheit zu beheben, anstatt die Software zu debuggen. Wenn Ihr erwartetes Ergebnis lautet: „Das System zeigt die Fehlermeldung ‚Ungültiges Passwort‘ an und hält den Benutzer auf der Anmeldeseite“, gibt es keinen Interpretationsspielraum. Das Ergebnis stimmt entweder überein oder nicht. Das ist die Zwei-Personen-Regel in der Praxis: Der Testfall ist der Ersteller, der Tester ist der Prüfer, und beide müssen dieselbe Sprache sprechen.
Sie verwandeln implizites Wissen in ein wiederverwendbares Gut. In den meisten Teams trägt der erfahrene QA-Ingenieur eine unsichtbare Karte aller Randfälle, aller Workarounds und aller „Ach ja, denk daran, auch X zu überprüfen“ mit sich. Wenn diese Person in Urlaub geht oder das Team wechselt, verschwindet diese Karte mit ihr. Dokumentierte Testfälle mit expliziten Vorbedingungen und Grenzwerten bewahren dieses Wissen in strukturierter Form. Ein neuer Tester, der zum Team stößt, kann sich TC_LOGIN_005 vornehmen und bereits am ersten Tag den Flow „Kontosperrung nach fünf Versuchen“ testen, ohne jemanden fragen zu müssen, wo die Schwelle liegt oder wie der Timer zurückgesetzt wird.
Sie isolieren Fehler auf genau definierte Schritte, nicht auf allgemeine Bereiche. Wenn ein Testfall „Zur Seite navigieren, Anmeldedaten eingeben und auf ‚Absenden‘ klicken“ in einem einzigen Schritt bündelt und der Test fehlschlägt, wissen Sie lediglich: „Irgendetwas im Anmelde-Flow ist schiefgelaufen.“ “ Wenn jede Aktion einen eigenen Schritt mit einem eigenen erwarteten Ergebnis darstellt, lässt sich der Fehler auf Schritt 4 eingrenzen: „Auf ‚Reset-Link senden‘ klicken → erwartete Erfolgsmeldung, 500-Fehler erhalten.“ Diese Präzision verkürzt die Debugging-Zeit erheblich, da der Entwickler genau weiß, welche Interaktion der Auslöser für den Fehler war – und nicht nur, in welchem Feature-Bereich er suchen muss.
Sie sehen, was abgedeckt ist und wo Lücken bestehen. Ohne strukturierte Testfälle ist die Testabdeckung reine Spekulation. Mit ihnen können Sie jeden Fall einer Anforderung zuordnen und Lücken sofort erkennen. Wenn Ihr Feature zum Zurücksetzen des Passworts sechs Szenarien umfasst (erfolgreiches Zurücksetzen, abgelaufener Link, wiederverwendeter Link, nicht registrierte E-Mail-Adresse, ungültiges Format, mehrere Anfragen) und Sie nur Testfälle für drei davon haben, ist die Lücke sichtbar und quantifizierbar. Diese Sichtbarkeit ist es, die das Testen von „Wir haben es getestet“ in „Hier ist genau das, was wir getestet haben, hier ist das, was wir nicht getestet haben, und hier ist das Risiko, das wir eingehen“ verwandelt.
Bestandteile eines guten Testfalls
Ein nützlicher Testfall beschreibt nicht nur, was getestet werden soll. Er erfasst den Kontext, die Ausführungsschritte und das erwartete Systemverhalten, sodass ein anderer Tester, Entwickler oder Produktmanager den Test reproduzieren und das Ergebnis überprüfen kann.
Die Bestandteile eines Testfalls sind:
- Eindeutige Kennung
- Zweck oder Beschreibung
- Voraussetzungen
- Ausführungsschritte
- Erwartete Lernergebnisse
- Tatsächliche Ergebnisse zum Vergleich
Für das oben genannte Beispiel zur Anmeldefunktion der Website sollte Ihr Testfall Folgendes enthalten:
Testfall-ID: Jeder Testfall benötigt eine eindeutige ID. Beim Testen eines Features erstellen QA-Teams häufig mehrere Testfälle, die ähnliche Bedingungen validieren. Die Testfall-ID hilft dabei, diese während der Fehlersuche oder bei der Berichterstellung leicht zu verfolgen, zu organisieren und darauf zu verweisen.
Beispiel: TC_LOGIN_001
Beschreibung: Hier wird erläutert, welche Funktionen der Testfall überprüft. Sie enthält eine kurze Zusammenfassung, damit jeder, der den Testfall liest, dessen Zweck sofort versteht.
Beispiel: Überprüfen Sie, ob sich ein registrierter Benutzer mit gültigen Anmeldedaten erfolgreich bei der Anwendung anmelden kann.
Vorbedingungen: Vorbedingungen beschreiben den Systemzustand, der vor der Ausführung des Testfalls erforderlich ist. Ohne sie könnten Tester denselben Test unter unterschiedlichen Bedingungen ausführen und inkonsistente Ergebnisse erhalten.
Beispiele:
- Das Konto des Benutzers muss bereits im System vorhanden sein
- Das Konto des Benutzers muss aktiv und darf nicht gesperrt sein
- Die Anmeldeseite sollte erreichbar sein
Schritte: Dies sind die Aktionen, die ein Benutzer oder Tester ausführt, um den Testfall auszuführen. Jeder Schritt sollte klar und sequenziell sein, damit jeder im Team den Test reproduzieren kann.
- Der Benutzer navigiert zur Anmeldeseite
- Der Benutzer gibt eine registrierte E-Mail-Adresse ein
- Der Benutzer gibt das richtige Passwort ein
- Der Benutzer klickt auf die Schaltfläche Anmelden
Erwartete Ergebnisse: Hier wird definiert, was das System tun sollte, wenn das Feature korrekt funktioniert.
- Wenn die Anmeldedaten gültig sind, führt das System die Authentifizierung des Benutzers durch
- Der Benutzer wird zum Dashboard weitergeleitet
- Eine Benutzersitzung wurde erfolgreich erstellt
Sind die Anmeldedaten ungültig, sollte das System die entsprechende Fehlermeldung anzeigen.
Tatsächliche Ergebnisse: Diese geben die Beobachtungen des Testers nach der Ausführung des Testfalls wieder. Weicht das beobachtete Verhalten vom erwarteten Ergebnis ab, wird das Problem als Problem protokolliert.
Beispiel für eine Beobachtung:
- Sie haben gültige Anmeldedaten eingegeben, aber den Fehler „Ungültiges Passwort“ erhalten.
Lassen Sie uns nun Ihre Fähigkeiten zum Verfassen von Testfällen in die Praxis umsetzen.
Wussten Sie schon? Nur 2,1 % der Teams bezeichnen ihre KI-Testverfahren als optimiert, während sich über 85 % noch in der Anfangs- oder Experimentierphase befinden. Am häufigsten wird KI zur Generierung von Testfällen eingesetzt (69,6 %), nicht für strategische Aufgaben wie die Risikoidentifizierung (19,9 %).
So verfassen Sie Testfälle (Schritt-für-Schritt-Anleitung)
Das Verfassen eines Testfalls umfasst sieben Schritte: Anforderung analysieren, Liste von Szenarien erstellen, Plan für die Struktur erstellen, Schritte mit erwarteten Ergebnissen formulieren, Anhang hinzufügen, prüfen lassen, ausführen und protokollieren.
Schritt 1: Analysieren Sie die Anforderungen
Bevor Sie den Testfall verfassen, sollten Sie verstehen, was das Feature zu erledigen hat. Dazu prüfen Sie die verfügbaren Dokumente – PRD (Product Requirement Documents), User Stories, Funktionsspezifikationen und Designdokumente – und identifizieren jede einzelne Funktion, die überprüft werden muss.
Beispiel: Sie entwickeln ein Feature, mit dem Benutzer ihr Passwort per E-Mail zurücksetzen können. Um einen Testfall dafür zu erstellen, müssen Sie Folgendes verstehen:
- Welches Problem löst das Feature, d. h., kann ein Benutzer wieder Zugriff auf sein Konto erhalten, wenn er sein Passwort vergessen hat?
- Welche Aktionen kann der Benutzer ausführen, d. h. einen Link zum Zurücksetzen anfordern, diesen per E-Mail erhalten und ein neues Passwort festlegen?
- Was sollte passieren, wenn diese Aktionen ausgeführt werden, d. h., sendet das System einen Link zum Zurücksetzen und ermöglicht es dem Benutzer, sein Passwort erfolgreich zu aktualisieren?
- Gibt es Einschränkungen, d. h., läuft der Link nach einer bestimmten Zeit ab oder wird er nach einmaliger Nutzung ungültig?
- Gibt es Validierungen oder Regeln, d. h. muss das neue Passwort bestimmte Anforderungen hinsichtlich Format oder Länge erfüllen?
- Ist eine Funktion vage oder unklar definiert? Wenn ja, holen Sie sich Klarheit bei den betroffenen Stakeholdern.
Diese Klarheit bildet die Grundlage dafür, ein klares Ziel für Ihren Testfall zu formulieren.
Ziel: Überprüfen Sie, ob ein registrierter Benutzer sein Passwort erfolgreich per E-Mail zurücksetzen kann.
Schritt 2: Identifizieren Sie verschiedene Testszenarien
Als Nächstes erstellen Sie eine Liste der Testszenarien, die Sie validieren müssen. Ein Testszenario ist eine übergeordnete Situation, die sich in der Regel in mehrere Testfälle verzweigt, die unterschiedliche Eingaben und Ergebnisse abdecken.
Für das Feature zum Zurücksetzen des Passworts könnten Ihre Szenarien wie folgt aussehen:
- Erfolgreiche Zurücksetzung: Überprüfen Sie, ob ein registrierter Benutzer einen Link zur Zurücksetzung anfordern und ein neues Passwort festlegen kann.
- Nicht registrierte E-Mail-Adresse: Testen Sie, was passiert, wenn eine E-Mail-Adresse übermittelt wird, die im System nicht existiert.
- Abgelaufener Link: Überprüfen Sie, ob das System den Zugriff blockt, wenn der Link zum Zurücksetzen nach Ablauf angeklickt wird.
- Wiederverwendeter Link: Testen Sie, ob ein bereits verwendeter Reset-Link nicht erneut verwendet werden kann
- Ungültiges neues Passwort: Stellen Sie sicher, dass Passwörter, die das Format nicht erfüllen, abgelehnt werden.
- Mehrere Reset-Anfragen: Testen Sie, welcher Link gültig bleibt, wenn ein Benutzer mehrere hintereinander anfordert.
Jedes hier beschriebene Szenario lässt sich in einen oder mehrere Testfälle umsetzen, die bestimmte Eingaben und Bedingungen abdecken. Durch diese Aufschlüsselung des Features stellen Sie sicher, dass Ihre Testabdeckung sowohl das erwartete Verhalten als auch die Randfälle umfasst, auf die echte Benutzer unweigerlich stoßen werden.
Schritt 3: Planen Sie den Test und legen Sie die Struktur der Testfälle fest
Für wiederkehrende Regressionstests benötigen Sie eine Struktur, mit der Sie Ihre Testfälle und deren Ergebnisse einheitlich dokumentieren können. Eine klar definierte Testfall-Vorlage sorgt für diese Einheitlichkeit und ermöglicht die Wiederverwendbarkeit, ohne jedes Mal von vorne beginnen zu müssen.
Planen Sie Ihre Testdurchführung, indem Sie folgende Elemente klären:
Wer wird den Test durchführen?
Welche Rolle oder Qualifikation benötigt die Person, die diesen Test durchführt? Weisen Sie je nach Komplexität des Tests und erforderlichem menschlichem Eingriff Rollen zu:
- QA-Tester: Funktions- und Regressionstests, wie z. B. die Überprüfung von Anmelde-Flows, Formularvalidierungen oder Kaufabwicklungsprozessen
- Sicherheitsteam: Tests im Zusammenhang mit Schwachstellen bei der Authentifizierung, der Zugriffskontrolle oder der Offenlegung von Daten
- Entwickler: Unit-Tests für einzelne Funktionen wie Passwort-Hashing oder Token-Generierung
Wie wird der Test durchgeführt?
- Auf welchen Geräten und Betriebssystemen wird der Test ausgeführt?
- Welche Tools oder Test-Frameworks werden verwendet?
- Wird der Test manuell oder durch einen KI-Agenten ausgeführt?
- Wie werden die Ergebnisse erfasst – in einem Testmanagement-Tool, einer Tabellenkalkulation oder einem Bug-Tracker?
Was sind die Voraussetzungen?
Listen Sie eine Liste aller Bedingungen auf, die vor Schritt 1 erfüllt sein müssen, und stellen Sie sicher, dass jede einzelne davon vom Tester überprüft werden kann:
Beispiel:
- Es existiert ein Benutzerkonto mit der E-Mail-Adresse „test@example.com“
- Der Benutzer ist aus dem System abgemeldet.
- Der E-Mail-Dienst ist aktiv und kann Nachrichten zustellen
- Die Testumgebung ist zugänglich und läuft
Welche Testdaten werden verwendet?
Definieren Sie die genauen Werte, die zur Durchführung des Tests benötigt werden – gültige Daten, ungültige Daten und Grenzwerte.
Beispiel:
- Gültig: registrierte E-Mail-Adresse „test@example.com“, Passwort entspricht den Format-Vorgaben
- Ungültig: nicht registrierte E-Mail-Adresse, Passwort unterhalb des Mindest-Zeichen-Limits
- Grenzwert: Passwort mit genau dem minimalen und maximalen Limit an Zeichen
Schritt 4: Verfassen Sie die Testschritte und die erwarteten Ergebnisse
Gliedern Sie den Ausführungsprozess in aufeinanderfolgende Schritte. Verwenden Sie eine einheitliche Terminologie und stellen Sie sicher, dass jeder Schritt eine einzige Aktion umfasst. Beschreiben Sie bei der Definition der Schritte auch das erwartete Ergebnis und legen Sie fest, was als „bestanden“ oder „nicht bestanden“ gilt.
In Fortsetzung unseres Flows zur Passwortzurücksetzung würden die Testschritte wie folgt aussehen:
| Schritte | Erwartetes Ergebnis |
| Zur Anmeldeseite wechseln | Die Anmeldeseite wird mit einem anklickbaren Link „Passwort vergessen“ geladen |
| Klicken Sie auf „Passwort vergessen“ | Der Benutzer wird auf die Seite zur Passwortzurücksetzung weitergeleitet. |
| Geben Sie Ihre E-Mail-Adresse in das E-Mail-Feld ein | Die E-Mail-Adresse wurde ohne Validierungsfehler akzeptiert |
| Klicken Sie auf „Link zum Zurücksetzen senden“ | Es erscheint folgende Erfolgsmeldung: „Reset-Link an test@example.com gesendet“ |
| Öffnen Sie den Link zum Zurücksetzen aus der E-Mail | Der Benutzer wird auf die Seite zur Erstellung eines neuen Passworts weitergeleitet. |
| Geben Sie ein gültiges neues Passwort ein | Das Passwort-Feld akzeptiert Eingaben ohne Fehlermeldung |
| Klicken Sie auf „Passwort zurücksetzen“ | Es wird eine Meldung über den Erfolg angezeigt, und der Benutzer wird auf die Anmeldeseite weitergeleitet. |
Definieren Sie nun Schritte und erwartete Ergebnisse für alternative Szenarien (wie zuvor besprochen). Beschreiben Sie, was passiert, wenn der Benutzer eine ungültige E-Mail-Adresse eingibt oder das Passwort nicht den vorgegebenen Kriterien entspricht.
Bonus: So können Sie die Dokumentation all Ihrer Testfälle mithilfe von KI automatisieren.
Schritt 5: Fügen Sie relevante Anhänge bei
Fügen Sie relevante Dokumente oder Anhänge bei, die den Testern helfen, den Testfall im vollständigen Kontext und ohne Unklarheiten auszuführen. Dazu können gehören:
- Kommentierte Screenshots der Benutzeroberfläche an wichtigen Schritten
- Bildschirmaufnahmen, die zeigen, wie der Test in verschiedenen Szenarien durchgeführt wird und welche Ergebnisse zu erwarten sind
- Systemprotokolle oder Konfigurationsdateien zur Diagnose von Backend-Problemen, wenn ein Test fehlschlägt
- Anforderungsdokumente, die den Testfall der User Story oder den Akzeptanzkriterien zuordnen, die er validiert
- Testdatendateien mit gültigen und ungültigen Eingaben oder generierten Daten wie Nummern von Kreditkarten, zufälligen Adressen oder Anmeldedaten für Benutzer
- Erstellen Sie eine Dokumentation, die die jeweilige Version der Software, die erforderliche Hardware, das Betriebssystem sowie etwaige erforderliche Freigaben für die Sicherheit abdeckt.
- Für API-Tests: OpenAPI-Spezifikationen oder Endpunktdokumentation mit detaillierten Angaben zu Anforderungsmethoden, Parametern und erwarteten Status-Codes
Schritt 6: Lassen Sie den Testfall überprüfen
Freigeben Sie den verfassten Testfall vor der Ausführung einem Kollegen oder einem erfahrenen QA-Leiter. Überprüfen Sie bei der Durchsicht Folgendes:
- Der Testfall ist umfassend und deckt alle möglichen Szenarien ab, die sich aus den Anforderungen ableiten lassen
- Die Schritte sind klar und stellen den tatsächlichen Flow der Ausführung schrittweise dar
- Jedes erwartete Ergebnis bezeichnet ein beobachtbares Ergebnis (eine Meldung, eine Weiterleitung, einen Status-Code) und keine Eigenschaft wie „funktioniert korrekt“.
- Testdaten und Voraussetzungen sind vollständig und korrekt
- Alle beim Verfassen getroffenen Annahmen werden ausdrücklich dokumentiert
Schritt 7: Ausführen und Ergebnisse protokollieren
Führen Sie den Test durch und protokollieren Sie das tatsächliche Ergebnis im Vergleich zu jedem erwarteten Ergebnis. Kennzeichnen Sie einen Test bei jedem Schritt als „bestanden“ oder „nicht bestanden“. Melden Sie bei jedem nicht bestandenen Schritt sofort einen Fehler und verknüpfen Sie diesen mit dem Testfall. Sollte zudem ein unerwartetes Verhalten auftreten, das nicht eindeutig als „bestanden“ oder „nicht bestanden“ eingestuft werden kann, notieren Sie dies im Kommentarfeld zur weiteren Überprüfung.
Weiterlesen: Wie man KI für die Qualitätssicherung einsetzt
Beispiele für das Verfassen von Testfällen
Diese drei Beispiele zeigen, wie sich dieselbe Testfallstruktur an verschiedene Arten von Softwaretests anpassen lässt. Jedes Beispiel verwendet die Komponenten und das Format der Schritte aus den vorherigen Abschnitten dieses Leitfadens, doch die Komplexität, die Testdaten und die Fehlermodi variieren je nachdem, was Sie überprüfen.
Beispiel 1: Checkout-Flow im E-Commerce (Benutzeroberfläche, mehrstufiger Workflow)
Ein QA-Team bei einem Online-Händler testet den Bestellvorgang vor einem Feiertagsverkauf. Der Flow erstreckt sich über mehrere Seiten: Warenkorb → Versand → Zahlung → Bestätigung. Die besondere Herausforderung hierbei ist die Zustandsabhängigkeit: Jeder Schritt hängt davon ab, dass der vorherige Schritt korrekt abgeschlossen wurde, und die Testdaten (Warenkorbinhalt, Lieferadresse, Zahlungsmethode) müssen über alle Schritte hinweg erhalten bleiben.
Tester: Rahul D.
Prüfungstermin: 09.03.2026
Testfall-ID: TC_CHECKOUT_003
Beschreibung: Überprüfen Sie, ob ein angemeldeter Benutzer einen Kauf mit einer gespeicherten Kreditkarte und Standardversand abschließen kann.
Voraussetzungen:
- Es existiert ein Benutzerkonto mit mindestens einer hinterlegten Kreditkarte und einer hinterlegten Lieferadresse
- Mindestens ein Element ist vorrätig und wurde in den Warenkorb gelegt
- Die Testumgebung läuft unter Chrome 128 und macOS
| Schritt | Erwartetes Ergebnis | Tatsächliches Ergebnis | Bestanden/Nicht bestanden |
| Zur Warenkorb-Seite wechseln | Der Warenkorb zeigt das richtige Element, die richtige Menge und die richtige Zwischensumme an | Wie erwartet | Bestanden |
| Klicken Sie auf „Zur Kasse gehen“ | Die Versandseite wird geladen, wobei die gespeicherte Adresse bereits als Auswahl vorausgewählt ist | Wie erwartet | Bestanden |
| Wählen Sie „Standardversand“ und klicken Sie auf „Weiter“ | Die Seite der Zahlung wird geladen und zeigt den Gesamtbetrag der Bestellung einschließlich Versandkosten an | Wie erwartet | Bestanden |
| Bestätigen Sie die hinterlegte Kreditkarte und klicken Sie auf „Bestellung aufgeben“ | Die Bestellbestätigungsseite wird mit Bestellnummer, Artikelübersicht und voraussichtlichem Liefertermin angezeigt. | Die Seite für die Zahlung wird mit folgender Fehlermeldung neu geladen: „Zahlung kann nicht verarbeitet werden“ | Fehlgeschlagen |
Zusammenfassung des Ergebnisses: Der Checkout-Flow verarbeitet den Übergang vom Warenkorb zur Versandadresse korrekt, doch die Zahlungsabwicklung schlägt bei gespeicherten Kreditkarten fehl. Gemeldeter Fehler: Die Abfrage der tokenisierten Karte läuft ab, wenn das Zahlungsgateway länger als 3 Sekunden für die Antwort benötigt.
Beispiel 2: REST-API-Endpunkt (ohne Benutzeroberfläche, Eingabe-/Ausgabevalidierung)
Ein Backend-Entwickler testet den API-Endpunkt „Create User“, bevor dieser vom Frontend-Team genutzt wird. Es gibt keine Benutzeroberfläche, durch die man sich klicken muss: Der Testfall validiert direkt die Request-Payloads, die Antwortcodes und die Datenpersistenz. Die besondere Herausforderung besteht darin, die Schnittstelle zwischen den Systemen zu testen, nicht die Benutzererfahrung.
Testerin: Sarah S.
Prüfungstermin: 09.05.2026
Testfall-ID: TC_API_USER_001
Beschreibung: Überprüfen Sie, ob eine POST-Anfrage an /api/v1/users einen neuen Benutzer anlegt und die richtige Antwort zurückgibt.
Voraussetzungen:
- Die API-Testumgebung ist in Betrieb und zugänglich
- Ein Auth-Token mit Berechtigungen für Administratoren wurde generiert und ist gültig
- In der Datenbank existiert kein Benutzer mit der E-Mail-Adresse „newuser@testdomain.com“
| Schritt | Erwartetes Ergebnis | Tatsächliches Ergebnis | Bestanden/Nicht bestanden |
| Senden Sie einen POST-Request an /api/v1/users mit folgender gültiger Nutzlast: { „name“: „Test Benutzer“, „E-Mail“: „newuser@testdomain.com“, „Rolle“: „viewer“ } | Die Antwort gibt „201 Created“ mit einem JSON-Body zurück, der Benutzer-ID, Name, E-Mail-Adresse und Rolle enthält. | 201 wurde mit korrektem Hauptteil zurückgegeben | Bestanden |
| Senden Sie dieselbe POST-Anfrage erneut mit derselben E-Mail-Adresse. | Die Antwort gibt den Status 409 „Konflikt“ mit der Meldung „Ein Benutzer mit dieser E-Mail-Adresse existiert bereits“ zurück. | 200 OK zurückgegeben; doppelter Benutzer angelegt | Fehlgeschlagen |
| POST-Anfrage mit fehlendem Feld „E-Mail“ senden | Die Antwort gibt den Status „400 Bad Request“ mit folgendem Validierungsfehler zurück: „E-Mail-Adresse ist erforderlich“ | 400 wurde wie erwartet zurückgegeben | Bestanden |
| Führen Sie eine GET-Abfrage an /api/v1/users/{id} mit der ID aus Schritt 1 durch | Die Antwort gibt „200 OK“ zurück, wobei die Daten des Benutzers mit der ursprünglichen Nutzlast übereinstimmen. | Wie erwartet | Bestanden |
Zusammenfassung der Ergebnisse: Der Endpunkt legt Benutzer korrekt an und validiert Pflichtfelder, setzt jedoch die E-Mail-Eindeutigkeit auf Datenbankebene nicht durch. Doppelte Datensätze wurden ohne Fehler angelegt. Fehler mit Schweregrad „Hoch“ protokolliert.
Beispiel 3: Rollenbasierte Zugriffskontrolle (Sicherheit, Berechtigungskreise)
Ein Sicherheitsteam prüft vor einem Compliance-Audit, ob die Anwendung Aktionen basierend auf Benutzerrollen korrekt einschränkt. Die besondere Herausforderung besteht darin, dass Sie nicht testen, ob ein Feature funktioniert, sondern ob ein Feature ordnungsgemäß verweigert wird. Das erwartete Ergebnis für die meisten Schritte ist ein Block, nicht ein Erfolg.
Tester: Marcus L.
Prüfungstermin: 09.08.2026
Testfall-ID: TC_RBAC_002
Beschreibung: Überprüfen Sie, ob ein Benutzer mit der Rolle „Viewer“ keine Projekte anlegen, bearbeiten oder löschen kann.
Voraussetzungen:
- Es gibt zwei Konten: eines mit der Rolle „Administrator“ und eines mit der Rolle „Viewer“
- Im Workspace ist mindestens ein Projekt vorhanden, das vom Administrator angelegt wurde.
- Der Nutzer ist mit Firefox 130 unter Windows 11 angemeldet.
| Schritt | Erwartetes Ergebnis | Tatsächliches Ergebnis | Bestanden/Nicht bestanden |
| Wechseln Sie zur Seite „Projekte“ | Der Betrachter sieht die Liste der Projekte im schreibgeschützten Modus; die Schaltfläche „Projekt erstellen“ ist entweder ausgeblendet oder deaktiviert. | Die Schaltfläche ist sichtbar, aber ausgegraut | Bestanden |
| Versuchen Sie, auf „Projekt erstellen“ zu klicken | Das System verhindert die Aktion; das Formular für ein neues Projekt wird nicht geladen | Es wurde kein Formular geladen; der Tooltip zeigt „Sie haben keine Berechtigung“ an. | Bestanden |
| Öffnen Sie ein bestehendes Projekt und versuchen Sie, die Bearbeitung des Titels durchzuführen. | Das Feld „Titel“ ist nicht für die Bearbeitung vorgesehen oder das System verhindert das Speichern | Das Titelfeld war für die Bearbeitung zugänglich; Änderungen wurden erfolgreich gespeichert | Fehlgeschlagen |
| Versuchen Sie, das Projekt über das Drei-Punkte-Menü zu löschen | Die Löschoption ist ausgeblendet oder die Aktion wird mit einem Fehler bei der Berechtigung blockiert | Die Option „Löschen“ hat im Menü keine Sichtbarkeit | Bestanden |
Zusammenfassung der Ergebnisse: Die Berechtigungen zum Erstellen und Löschen sind für Betrachter korrekt eingeschränkt, die Berechtigungen für die Bearbeitung werden jedoch auf Feldebene nicht durchgesetzt. Ein Betrachter kann Projekt-Titel ändern, obwohl er nur Lesezugriff hat. Der Fehler wurde mit dem Schweregrad „Kritisch“ (Compliance-Blockierer) protokolliert.
Welche tools eignen sich am besten für die Verwaltung von Testfällen?
Testfälle können in einem speziellen QA-Tool (TestRail, Zephyr), einem allgemeinen Projektmanagement-Tool (ClickUp, Jira) oder einer Tabellenkalkulation verwaltet werden; die richtige Wahl hängt davon ab, ob Sie eine integrierte Ausführungsfunktion benötigen oder lediglich die Nachverfolgung.
ClickUp
ClickUp for Software Teams ist eine Projektmanagement-Plattform, auf der Testfälle als Aufgaben neben den Sprints, Fehlern und Pull Requests gespeichert werden, auf die sie sich beziehen. Es handelt sich nicht um ein spezielles Testmanagement-Tool, aber dank der flexiblen Aufgabenstruktur können Teams Testfall-Workflows mit benutzerdefinierten Status, Feldern und Aufgabentypen erstellen, ohne ein separates Tool zu benötigen.
Die wichtigsten Features von ClickUp
- Flexible Hierarchie zur Organisation von Testfällen über Spaces, Ordner und Listen hinweg mit benutzerdefinierten Feldern für Testtyp, Priorität und Umgebung
- Über 15 ClickUp-Ansichten (Board, Liste, Tabelle) zur Nachverfolgung der Testausführung nach Status, Mitarbeiter oder Sprint
- Dokumente zur Aufbewahrung von PRDs, Testplänen und Anleitungen zum Setup neben den Testfällen, auf die sie sich beziehen
- Integrierter Chat für die Kommunikation zwischen QA-Mitarbeitern und Entwicklern, ohne auf Slack oder E-Mail umschalten zu müssen
- KI-gestützte Aufgabenzusammenfassungen über ClickUp Brain für einen schnellen Überblick während Sprint-Reviews
Limitierungen von ClickUp
- Keine native Testausführungs-Engine
- Testspezifische Berichte (Abdeckung nach Anforderungen, Erfolgsquote pro Zyklus) erfordern benutzerdefinierte Dashboards anstelle von vorgefertigten Berichten zur QA-Berichterstellung.
Preise für ClickUp
ClickUp-Bewertungen und Rezensionen
- G2: 4,6/5 (über 14.100 Bewertungen)
- Capterra: 4,6/5 (über 4.600 Bewertungen)
Was sagen echte Benutzer über ClickUp?
Das sagt ein G2-Rezensent dazu:
Was mir an ClickUp am besten gefällt, ist, dass es alles an einem Ort vereint. Aufgaben, Zeitleisten, Notizen und Updates befinden sich alle im selben System, was das Hin- und Herwechseln zwischen verschiedenen Tools reduziert. Außerdem schätze ich die Flexibilität. Wir können Status, Felder und Ansichten so anpassen, dass sie der tatsächlichen Arbeitsweise unseres Teams entsprechen. Das erleichtert es, den Überblick zu behalten, und bietet jederzeit einen klaren Einblick darin, wer für was verantwortlich ist und wo die Projekte gerade stehen.
Was mir an ClickUp am besten gefällt, ist, dass es alles an einem Ort vereint. Aufgaben, Zeitleisten, Notizen und Updates befinden sich alle im selben System, was das Hin- und Herwechseln zwischen verschiedenen Tools reduziert. Außerdem schätze ich die Flexibilität. Wir können Status, Felder und Ansichten so anpassen, dass sie der tatsächlichen Arbeitsweise unseres Teams entsprechen. Das erleichtert die Organisation und bietet jederzeit einen klaren Überblick darüber, wer für was verantwortlich ist und wie der Stand der Projekte ist.
Ideal für: Einen QA-Leiter, der möchte, dass ein fehlgeschlagener Test mit einem Klick zu einem Bug-Ticket für den Entwickler wird, wobei der PR, die Testschritte und der Sprint alle in derselben Aufgabe sichtbar sind.
Überspringen Sie diesen Abschnitt, wenn: Ihr Testzyklus größtenteils durch Automatisierung unterstützt wird. Wenn 80 % Ihrer Testsuite über eine CI-Pipeline ausgeführt werden, benötigen Sie ein tool, das die Ergebnisse der Ausführung automatisch erfasst, und keines, bei dem ein Mitarbeiter den Status manuell aktualisieren muss.
TestRail
TestRail ist eine spezielle Testmanagement-Plattform für QA-Teams, die eine strukturierte Steuerung ihres gesamten Testprozesses benötigen. Sie deckt den gesamten Zyklus vom Erstellen über das Ausführen bis hin zur Berichterstellung von Testfällen ab, wobei Ergebnisse aus DevOps- und CI/CD-Integrationen einfließen.
Die wichtigsten Features von TestRail
- Zentralisierte Verwaltung von Testfällen und Testsuiten mit projektübergreifend wiederverwendbaren Testfällen
- Testpläne und Meilensteine zur Organisation und Planung von Testläufen über Sprints und Releases hinweg
- Detaillierte Berichterstellung mit Abdeckungsanalyse, Nachverfolgung des Fortschritts und Ausführungsverlauf
- Integrationen mit Jira, GitHub, Jenkins, Azure DevOps und über 20 weiteren DevOps-Tools
- REST-API zur Automatisierung von Aufgaben und zur Synchronisierung von Testdaten mit externen Systemen
Limitierungen von TestRail
- Da es keine integrierten Funktionen für die Anforderungsverwaltung oder die Nachverfolgung von Problemen gibt, müssen sich Teams auf externe Tools wie Jira verlassen, was die Rückverfolgbarkeit beeinträchtigen kann
- Eine ordnerbasierte Organisation wird unübersichtlich, wenn Test-Repositorys auf Tausende anwachsen
Preise für TestRail
- Professional: 39 $ pro Platz und Monat
- Enterprise: 78 $ pro Platz und Monat
Bewertungen und Rezensionen zu TestRail
- G2: 4,4/5 (über 600 Bewertungen)
- Capterra: 4,3/5 (über 160 Bewertungen)
Was sagen echte Benutzer über TestRail?
Das sagt ein G2-Rezensent dazu:
Was ich an TestRail am wertvollsten finde, ist, dass es unserem QA-Team eine sichere und gut organisierte Umgebung zur Verwaltung von Testplänen, Testfällen und Testläufen bietet. Ich schätze besonders, wie einfach es ist, Testsuiten zu strukturieren und zu implementieren sowie bereits erstellte Testfälle wiederzuverwenden. Die Integrationen mit Jira und CI/CD-Tools haben unseren Workflow einheitlicher und leichter zur Nachverfolgung gemacht. Die Möglichkeit, den Testfortschritt und die Testabdeckung in Echtzeit zu überwachen, war für die Sprint-Planung und Berichterstellung unglaublich hilfreich. In meiner täglichen Arbeit als QA-Ingenieur hat mir die Nutzung von TestRail zudem viel Zeit gespart.
Was ich an TestRail am wertvollsten finde, ist, dass es unserem QA-Team eine sichere und gut organisierte Umgebung zur Verwaltung von Testplänen, Testfällen und Testläufen bietet. Ich schätze besonders, wie einfach es ist, Testsuiten zu strukturieren und zu implementieren sowie bereits erstellte Testfälle wiederzuverwenden. Die Integrationen mit Jira und CI/CD-Tools haben unseren Workflow einheitlicher und leichter für die Nachverfolgung gemacht. Die Möglichkeit, den Testfortschritt und die Testabdeckung in Echtzeit zu überwachen, war für die Sprint-Planung und Berichterstellung unglaublich hilfreich. In meiner täglichen Arbeit als QA-Ingenieur hat mir die Nutzung von TestRail zudem viel Zeit gespart.
Am besten geeignet für: Ein QA-Team mit fünf oder mehr Mitarbeitern, das pro Release formale Zyklen durchführt, wobei ein Manager die Frage „Wie viel Prozent von Release 2.0 wurden ausgeführt und bestanden?“ anhand eines Dashboards und nicht anhand einer Tabellenkalkulation beantworten muss.
Überspringen Sie diesen Abschnitt, wenn: Ihre Testsuite weniger als ein paar hundert Fälle umfasst oder Ihre Tester gleichzeitig als Entwickler tätig sind. Bei diesem Umfang sind die Kosten pro Platz und der separate Login nur eine Investition in die Berichterstellung, die Sie ohnehin nicht einsehen werden.
Zephyr
Zephyr ist das Testmanagement-Plugin von SmartBear für Jira, das entwickelt wurde, um Testfälle direkt über die Jira-Oberfläche zu verwalten. Es unterstützt sowohl manuelle als auch automatisierte Tests und bietet leistungsstarke Features für die Berichterstellung und Rückverfolgbarkeit für agile Teams und Teams von Unternehmen.
Die wichtigsten Features von Zephyr
- Native Jira-Integration – erstellen, verknüpfen und führen Sie Testfälle direkt aus Jira-Problemen heraus aus
- Projektübergreifende hierarchische Testbibliotheken zur Wiederverwendung und Organisation von Testfällen in großem Umfang
- Über 70 vordefinierte Berichte zu Testabdeckung, Ausführungsfortschritt und Fehlernachverfolgung
- BDD-Support mit Gherkin-Syntax für Workflows der verhaltensgetriebenen Entwicklung
- CI/CD-Integrationen mit Jenkins, GitHub, Gitlab, Bitbucket und Bamboo
Limitierungen von Zephyr
- Lizenzierung pro Jira-Benutzer, nicht pro Tester
- Die Navigation in großen Test-Repositorys (mit Tausenden von Testfällen) kann sich mühsamer anfühlen als in eigenständigen tools wie TestRail
- Der Support wird über den Atlassian Marketplace abgewickelt, was für Teams, die an direkten Hersteller-Support gewöhnt sind, eine zusätzliche Ebene darstellt
Preise für Zephyr
- Essential: ab 5,99 $ pro Benutzer und Monat (11–50 Benutzer)
- Standard: ab 6,81 $ pro Benutzer und Monat (11–50 Benutzer)
- Advanced: ab 8,73 $ pro Benutzer und Monat (11–50 Benutzer)
Bewertungen und Rezensionen zu Zephyr
- G2: 4,1/5 (über 80 Bewertungen)
- Capterra: Zu wenige Bewertungen
Was sagen echte Benutzer über Zephyr?
Das sagt ein G2-Rezensent dazu:
Dies ist das beste tool, um Testfälle direkt aus einer Excel-Tabelle zu importieren. Mit diesem Tool ist der Arbeitsaufwand für Tester geringer als beim Importieren von Testfällen in Jira. Ein weiteres herausragendes Feature dieses Tools ist die Möglichkeit, Testfälle als bestanden oder nicht bestanden zu kennzeichnen und Anhänge hinzuzufügen.
Dies ist das beste tool, um Testfälle direkt aus einer Excel-Tabelle zu importieren. Mit diesem tool ist die Arbeit der Tester geringer als beim Importieren von Testfällen in Jira. Ein weiteres hervorragendes Feature dieses tools ist die Möglichkeit, Testfälle als bestanden oder nicht bestanden zu kennzeichnen und Anhänge hinzuzufügen.
Am besten geeignet für: Teams in regulierten oder stark auditierten Branchen (Fintech, Gesundheitswesen), bei denen jeder Test auf eine Jira-Anforderung zurückverfolgt und jeder Fehler mit dem Test verknüpft werden muss, durch den er entdeckt wurde – und das alles innerhalb einer einzigen Atlassian-Instanz.
Überspringen Sie diesen Abschnitt, wenn: Ihre Jira-Instanz groß ist und Ihr QA-Team klein ist. Eine Jira-Instanz mit 200 Lizenzen und 10 Testern kostet 190 Zephyr-Lizenzen, die niemand nutzt; ein eigenständiges tool, dessen Preis pro Tester berechnet wird, ist günstiger.
Jira
Jira ist die Plattform für Projektmanagement und Issue-Tracking von Atlassian, die von Entwicklungs- und QA-Teams häufig zur Verwaltung von Sprints, Problemen und Workflows genutzt wird. Obwohl es sich nicht um ein spezielles Testmanagement-Tool handelt, setzen viele Teams es zusammen mit Tools wie Zephyr Scale oder Xray ein, um das Testfallmanagement innerhalb ihres bestehenden Jira-Setups zu bewältigen.
Wichtige Features von Jira
- Scrum- und Kanban-Boards zur Verwaltung von Sprints, Backlogs und agilen Test -Workflows
- Anpassbare Workflows, Problemtypen und Felder, die genau auf die Art der Nachverfolgung durch Ihr Team zugeschnitten sind
- Erweiterte Roadmaps für teamübergreifende Planung und Nachverfolgung von Abhängigkeiten (Premium)
- Über 1.000 Marktplatz-Integrationen, darunter GitHub, Confluence, Slack und CI/CD-Tools
- Automatisierungsregeln als Auslöser für Aktionen auf Projekt-Ebene auf Basis von Problemaktualisierungen oder Status-Änderungen
Limitierungen von Jira
- Für das Testfallmanagement ist ein Marketplace-Plugin (Zephyr Scale, Xray) erforderlich, für das zusätzlich zum Jira-Abonnement eine eigene Gebühr pro Benutzer anfällt.
- Steilere Lernkurve für nicht-technische Benutzer, wobei sich die Einarbeitungskosten bei größeren Teams summieren können
Jira-Preise
- Free
- Standard: 7,91 $ pro Benutzer und Monat
- Premium: 14,54 $ pro Benutzer und Monat
- Enterprise: Benutzerdefinierte Preisgestaltung
Jira-Bewertungen und Rezensionen
- G2: 4,3/5 (über 7.900 Bewertungen)
- Capterra: 4,4/5 (über 15.400 Bewertungen)
Was sagen echte Benutzer über Jira?
Das sagt ein G2-Rezensent dazu:
Jira ist eines meiner bevorzugten digitalen Programme zur Nachverfolgung und Visualisierung des Fortschritts aller meiner Arbeitsprojekte in Zusammenarbeit mit allen Mitgliedern meines Arbeitsteams, da es die besten virtuellen Leistungsfunktionen seiner Klasse bietet und es mir so erleichtert, alle meine beruflichen Ziele zu erreichen.
Jira ist eines meiner bevorzugten digitalen Programme zur Nachverfolgung und Visualisierung des Fortschritts all meiner Arbeitsprojekte in Zusammenarbeit mit allen Mitgliedern meines Teams, da es die besten virtuellen Leistungsfunktionen seiner Klasse bietet und es mir so erleichtert, alle meine beruflichen Ziele zu erreichen.
Am besten geeignet für: Entwicklerteams, die prüfen möchten, ob sie überhaupt ein spezielles Testmanagement benötigen. Wenn Sie zunächst einige Zyklen als benutzerdefinierte Jira-Problem-Typen durchführen, lässt sich feststellen, ob der Umfang den Einsatz eines Plugins rechtfertigt.
Überspringen Sie diesen Abschnitt, wenn: Sie bereits wissen, dass Sie Testmanagement benötigen. Wenn Sie direkt zu einem Plugin oder einem eigenständigen tool übergehen, vermeiden Sie die Migration, sobald benutzerdefinierte Issue-Typen nicht mehr skalierbar sind.
Häufige Fehler, die Sie beim Erstellen von Testfällen vermeiden sollten
Vermeiden Sie diese Fehler beim Verfassen von Testfällen, die deren allgemeine Wirksamkeit beeinträchtigen können.
| Fehler | Was Sie stattdessen zu erledigen haben |
|---|---|
| Zu späte Erstellung von Testfällen | Beziehen Sie Tester in die Anforderungserfassung und die Entwurfsphase ein, um potenzielle Probleme zu erkennen, bevor mit der Programmierung begonnen wird. |
| Testfälle werden nicht aktualisiert | Aktualisieren Sie den Testfall, sobald das Feature ein neues Upgrade erhält, sich die Funktionalität ändert oder die Benutzeroberfläche angepasst wird. |
| Keine Nachbedingungen | Geben Sie an, wie das System nach Abschluss des Tests aussehen soll (Testbenutzer gelöscht, Warenkorb geleert, Sitzung geschlossen), damit der nächste Testfall in einem sauberen Zustand beginnt. |
| Nur Daten aus dem Happy Path | Jedes Feld benötigt mindestens einen Wert, den das System ablehnen sollte. Dokumentieren Sie, wie der Datensatz generiert oder abgerufen wird. |
| Keine Priorisierung von Testfällen | Weisen Sie jedem Testfall eine Priorität zu, basierend auf den geschäftlichen Auswirkungen, der Nutzungshäufigkeit und dem Ausfallrisiko. Dies hilft Ihnen, Ihren Aufwand für Tests zu fokussieren und fundiertere Entscheidungen hinsichtlich Budget und Testmethoden zu treffen. |
So bleiben Testfälle auch langfristig nützlich
Eine Testsuite bleibt vertrauenswürdig, wenn jeder Testfall unabhängig ist, auf die Eingaben abzielt, die am ehesten zu Fehlern führen, und ausgemustert wird, sobald er kein zuverlässiges Ergebnis mehr liefert. Diese sechs Vorgehensweisen unterscheiden Suiten, die über Jahre hinweg Fehler aufspüren, von solchen, die bereits nach dem zweiten Sprint ignoriert werden.
Schreiben Sie unabhängige, atomare Tests
Ein Testfall sollte seinen eigenen Zustand schaffen und niemals von einer Abhängigkeit zu einem anderen Fall betroffen sein. Wenn TC_CHECKOUT_003 davon ausgeht, dass TC_CHECKOUT_002 ein Element im Warenkorb zurückgelassen hat, führt ein Fehler zu fünf weiteren, und Sie verbringen den Vormittag damit, herauszufinden, welcher Fehler tatsächlich aufgetreten ist. Wenn ein Testtitel das Wort „und“ enthält, teilen Sie ihn in zwei Fälle auf.
Testen Sie an den Grenzen
Fehler treten vor allem an den Rändern des zulässigen Eingabebereichs auf, nicht in der Mitte. Wenn ein Passwortfeld 8 bis 128 Zeichen akzeptiert, testen Sie 7, 8, 128 und 129 – und nicht nur ein bequemes 12-Zeichen-Passwort. Die Grenzwertanalyse ist genau aus diesem Grund eine formale Technik im Testdesign-Standard ISO/IEC/IEEE 29119-4: Sie deckt „Off-by-One“-Fehler auf, die bei zufälligen Eingaben übersehen werden.
Nutzen Sie Äquivalenzpartitionierung, um redundante Fälle zu vermeiden
Gruppieren Sie Eingaben, die das System identisch behandeln soll, und testen Sie dann jeweils einen repräsentativen Wert aus jeder Gruppe. Jedes gültige E-Mail-Format verhält sich in einem Anmeldeformular gleich, daher reicht eine gültige E-Mail-Adresse aus. Das Testen von user@example.com, jane@company.com und bob@domain.org als drei separate Fälle verdreifacht Ihren Wartungsaufwand, ohne die Testabdeckung zu erhöhen.
Trenne Testdaten von Testschritten
Das Festschreiben von „enter test@example.com“ in einem Schritt bedeutet, dass der Schritt jedes Mal neu geschrieben werden muss, wenn sich die Testumgebung ändert. Halten Sie Schritte allgemein gehalten („eine registrierte E-Mail-Adresse eingeben“) und speichern Sie die tatsächlichen Werte in einem Testfeld oder einer Datei. Die gleichen Schritte lassen sich dann ohne Änderungen in der Phase, im Qualitätsmanagement und in der Vorproduktionsumgebung ausführen, und das Einfügen eines neuen Datensatzes für einen Negativtest erfordert lediglich eine Änderung von einer Zeile.
Nachverfolgung unzuverlässiger Tests und der Fehlerdurchlassrate
Ein unzuverlässiger Test schlägt unregelmäßig fehl, ohne dass ein echter Produktfehler vorliegt, und jeder unzuverlässige Test bringt dem Team bei, rote Ergebnisse zu ignorieren. Verfolgen Sie, wie oft jeder Testfall bei identischen Builds zwischen „bestanden“ und „nicht bestanden“ wechselt. Wenn ein Testfall öfter als ein paar Mal im Monat unzuverlässig ist, schreiben Sie ihn um oder entfernen Sie ihn. Kombinieren Sie dies mit der Fehlerdurchbruchsrate (Fehler, die in der Produktion gefunden wurden, die ein Testfall hätte abfangen sollen), um zu erkennen, wo die Abdeckung lückenhaft ist – und nicht nur, wo sie ungenau ist.
Automatisieren Sie die Tests, die Sie am häufigsten ausführen
Regressions-, Smoke- und hochfrequente Funktionstestfälle eignen sich am besten für die Automatisierung, da sie bei jedem Build ausgeführt werden und sich selten ändern. Übertragen Sie diese in Skripte in Ihrer CI/CD-Pipeline und nutzen Sie KI-gestützte Tools mit selbstheilenden Locators an Stellen, an denen sich UI-Elemente häufig verschieben. Dadurch werden menschliche Tester für explorative Arbeiten und für Arten von Softwaretests entlastet, die Urteilsvermögen erfordern, wie beispielsweise Usability-Tests und die Suche nach Randfällen.
So verfassen und führen Sie Testfälle in ClickUp durch
Im obigen Abschnitt „Tools“ wird erläutert, wo ClickUp zum Einsatz kommt. Dieser Abschnitt zeigt das konkrete Setup, abgestimmt auf die Schritte aus dem vorherigen Teil des Leitfadens.
Strukturieren Sie Ihre Testfallbibliothek. Erstellen Sie einen Bereich für Ihr Produkt, einen Ordner für jeden Funktionsbereich (z. B. Authentifizierung, Zahlungen, Onboarding) und eine Liste für jeden Zyklus oder Sprint. Jede Aufgabe wird zu einem einzelnen Testfall. Verwenden Sie die benutzerdefinierten Felder von ClickUp, um Komponenten wie Testfall-ID, Voraussetzungen, Testdaten, Prioritätsstufe und Umgebung zu erfassen.
Schreiben Sie Testschritte direkt in die Aufgabe. Nutzen Sie die Aufgabenbeschreibung, um die aufeinanderfolgenden Ausführungsschritte und die erwarteten Ergebnisse zu dokumentieren. Checklisten eignen sich gut für schrittweise Flows, bei denen ein Tester jede Aktion abhaken muss, während die Beschreibung den Kontext wie Vorbedingungen und Testdaten enthält.
Verfolgen Sie die Ausführung und die Ergebnisse. Erstellen Sie benutzerdefinierte Status, die Ihren Test-Workflow widerspiegeln: Nicht begonnen → In Bearbeitung → Bestanden → Fehlgeschlagen → Blockiert. Wenn ein Test fehlschlägt, wandeln Sie ihn in eine Fehlermeldung um oder erstellen Sie eine verknüpfte Aufgabe, die dem Entwickler zugewiesen wird – mit Priorität, Abhängigkeiten und einer Frist. Über die GitHub- und Gitlab-Integrationen können Sie diesen Fehler direkt mit dem Pull Request verknüpfen, durch den er verursacht wurde. Wenn die Ursache ein Codefehler ist, können Sie diese Fehleraufgabe dem ClickUp Codegen Agent zuweisen, der die Aufgabe, die verknüpften Spezifikationen und Kommentare liest, die Korrektur schreibt und einen Pull Request eröffnet, dessen Fortschritt wieder in die Aufgabe zurückgemeldet wird.
Profi-Tipp: QA-Leiter können sich einen sofortigen Überblick über jede Aufgabe verschaffen, indem sie ClickUp Brain bitten, offene Bug-Aufgaben zusammenzufassen. Auf diese Weise verfügen sie über den gesamten Kontext, den sie für Sprint-Reviews benötigen, ohne einzelne Aufgaben durchforsten zu müssen, um sich ein Gesamtbild zu verschaffen.
Führen Sie Testzyklen mit verschiedenen Ansichten durch. Verwenden Sie die nach Status gruppierte Board-Ansicht, um während eines Testlaufs die Verteilung von „bestanden“ und „nicht bestanden“ auf einen Blick zu erkennen. Die Tabelle fungiert als herkömmliche Testmatrix, wenn Sie die Ergebnisse von Dutzenden von Testfällen überblicken müssen. Filtern Sie nach Mitarbeitern, um die Workload auszugleichen, oder nach Priorität, um bei einem Smoke-Test zunächst die kritischen Pfade zu prüfen.
Die ClickUp-Vorlage für das Testmanagement bietet Ihnen eine zentralisierte Möglichkeit, den gesamten Test-Workflow über mehrere Features, Testszenarien und Randfälle hinweg an einem Ort zu verwalten. Nutzen Sie sie für die Nachverfolgung von Nutzer-Feedback, um Testpläne zu verwalten, den Fortschritt Ihrer Tests zu überwachen und die Ergebnisse (bestanden/nicht bestanden) auszuwerten, ohne zwischen verschiedenen tools hin- und herwechseln zu müssen.
Verwalten Sie Ihre Workflows für Tests effektiv
Ein Testfall hat sich bewährt, sobald zwei Personen ihn unabhängig voneinander ausführen können und dabei zum gleichen Ergebnis – „bestanden“ oder „nicht bestanden“ – gelangen. Alles in diesem Leitfaden (eine Aktion pro Schritt, explizite Voraussetzungen, erwartete Ergebnisse ohne Interpretationsspielraum) dient diesem einen Standard. Wenn Sie bereits Sprints in ClickUp planen, können Sie mit dem oben beschriebenen Setup Testfälle schreiben, ausführen und nachverfolgen – zusammen mit den dadurch aufgedeckten Fehlern –, ohne ein weiteres tool hinzuzufügen.
Melden Sie sich kostenlos bei ClickUp an
Häufig gestellte Fragen zu Testfällen
Wie viele Testfälle sollte eine Anforderung umfassen?
Eine einzelne Anforderung kann einen oder auch zehn Testfälle erfordern, je nachdem, wie viele Szenarien, Randfälle und Eingabevariationen sie umfasst. Das Ziel ist es, alle realistischen Abläufe abzudecken und dabei eine ausreichende Abdeckung ohne Redundanzen zu gewährleisten.
Was ist der Unterschied zwischen Testfällen und Testskripten?
Ein Testfall dokumentiert, was getestet werden soll und welches Ergebnis zu erwarten ist, und ist für die manuelle Ausführung gedacht. Ein Testskript hingegen ist die automatisierte Version: Code, der dieselben Schritte programmgesteuert ausführt.
Wie detailliert sollten Testschritte sein?
Gliedern Sie den Test in logische, aufeinanderfolgende Schritte, die auch ohne Vorkenntnisse leicht nachzuvollziehen sind. Bündeln Sie nicht mehrere Aktionen und vermeiden Sie unnötige Komplexität.
Ein Testszenario gibt in einer Zeile an, was getestet werden soll („Passwortzurücksetzung überprüfen“); ein Testfall legt wie dies geschehen soll fest, einschließlich Vorbedingungen, Schritten, Testdaten und erwarteten Ergebnissen. Aus einem Szenario ergeben sich in der Regel 3 bis 10 Testfälle, die den Normalfall, ungültige Eingaben und Randbedingungen abdecken. Szenarien stehen an erster Stelle und bestimmen den Plan für die Testabdeckung; Testfälle folgen an zweiter Stelle und bestimmen die Durchführung.
Ein positiver Testfall verwendet gültige Eingaben und erwartet einen Erfolg: Mit korrekter E-Mail-Adresse und korrektem Passwort wird der Benutzer angemeldet. Ein negativer Testfall verwendet ungültige oder unerwartete Eingaben und erwartet, dass das System fehlerfrei reagiert: Bei einem falschen Passwort wird „Ungültiges Passwort“ angezeigt, ohne dass eine Sitzung erstellt wird. Ausgereifte Testsuiten weisen ein Verhältnis von positiven zu negativen Testfällen von etwa 1:3 bis 1:5 auf, da die meisten Fehler in der Produktion in Fehlerpfaden auftreten, nicht in „Happy Paths“.
Ein Plan definiert den Umfang, den Ansatz, die Ressourcen und den Zeitplan für den gesamten Aufwand. Eine Testsuite ist eine Sammlung von Testfällen, die für einen einzelnen Durchlauf zusammengefasst sind, beispielsweise „Regressionssuite für Release 2.1“. Ein Testfall ist die kleinste Einheit in beiden: eine dokumentierte Prüfung mit einem Ergebnis (bestanden/nicht bestanden). Der Plan legt die Strategie fest, die Suite den Umfang und der Testfall das Ergebnis.