So erstellen Sie effektive Testfälle (mit Beispielen)

Die meisten Testfälle scheitern, bevor sie auch nur einen einzigen Fehler aufdecken. Sie sind als vage Checklisten verfasst, lassen Voraussetzungen 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 Befehle spricht man von der „Zwei-Personen-Regel“. Das Prinzip ist dasselbe: Kritische Arbeiten sollten niemals von einer einzigen, ungeprüften Aktion abhängen. Ein gut geschriebener Testfall überträgt diese Strenge auf die Software. 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 erstellen, warum sie wichtig sind und wie Sie die Qualität Ihrer Testfälle im Laufe der Zeit verbessern können.

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:

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“ die Erstellung von Testfällen (69,6 %) und die Pflege von Skripten (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.

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, der eine markiert ihn als bestanden, der andere meldet einen Fehler – und schon muss das Team die Meinungsverschiedenheit beheben, anstatt die Software. 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 eine wiederverwendbare Ressource. In den meisten Teams verfügt der erfahrene QA-Ingenieur über eine unsichtbare Karte aller Randfälle, aller Workarounds und aller „Ach ja, überprüfen Sie auch unbedingt X“-Hinweise. Wenn diese Person in Urlaub geht oder das Team wechselt, nimmt sie diese Karte mit. Dokumentierte Testfälle mit expliziten Vorbedingungen und Grenzwerten bewahren dieses Wissen strukturell. Ein neuer Tester, der dem Team beitritt, 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 bestimmte Schritte, nicht auf allgemeine Bereiche. Wenn ein Testfall „Zur Seite navigieren, Anmeldedaten eingeben und auf ‚Absenden‘ klicken“ zu 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 drastisch, da der Entwickler genau weiß, welcher Auslöser den Fehler ausgelöst hat – 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, was wir getestet haben, hier ist, 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:

Für das oben genannte Beispiel zur Anmeldefunktion auf einer Website sollte Ihr Testfall Folgendes umfassen:

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 beim Debuggen oder bei der Berichterstellung einfach zu verfolgen, zu organisieren und darauf zu verweisen.

Beispiel: TC_LOGIN_001

Beschreibung: Hier wird erläutert, welche Funktionen der Testfall überprüft. Die Beschreibung 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.

Voraussetzungen: Voraussetzungen 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:

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.

Erwartete Ergebnisse: Hier wird definiert, was das System zu erledigen hat, wenn das Feature korrekt funktioniert.

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.

Beispielbeobachtung:

Lassen Sie uns nun Ihre Fähigkeiten zum Verfassen von Testfällen in die Praxis umsetzen.

So schreiben Sie Testfälle (Schritt-für-Schritt-Anleitung)

Das Verfassen eines Testfalls umfasst sieben Schritte: Analyse der Anforderung, Liste der Szenarien, Plan der Struktur, Verfassen der Schritte mit den erwarteten Ergebnissen, Anhang mit Kontext, Überprüfung, Ausführung und Protokollierung.

Schritt 1: Analysieren Sie die Anforderungen

Bevor Sie den Testfall schreiben, sollten Sie verstehen, was das Feature leisten soll. Dazu prüfen Sie die verfügbaren Dokumente – PRDs (Produktanforderungsdokumente), User Stories, Funktionsspezifikationen und Designdokumente – und identifizieren jede 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 entsprechenden Testfall zu erstellen, müssen Sie Folgendes verstehen:

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:

Jedes der hier beschriebenen Szenarien wird in einen oder mehrere Testfälle umgesetzt, die bestimmte Eingaben und Bedingungen abdecken. Durch diese Aufschlüsselung des Features stellen Sie sicher, dass Sie sowohl das erwartete Verhalten als auch die Randfälle abdecken, 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 Wiederverwendung, ohne jedes Mal von vorne anfangen zu müssen.

Planen Sie Ihre Testdurchführung, indem Sie folgende Punkte klären:

Wer wird den Test durchführen?

Welche Rolle oder Qualifikation muss die Person haben, die diesen Test durchführt? Weisen Sie je nach Komplexität des Tests und erforderlichem menschlichem Eingriff Rollen zu:

Wie wird der Test durchgeführt?

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 davon vom Tester überprüft werden kann:

Beispiel:

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:

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. Geben Sie bei der Definition der Schritte auch das erwartete Ergebnis an 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:

Definieren Sie nun Schritte und erwartete Ergebnisse für alternative Szenarien (wie zuvor erläutert). Beschreiben Sie, was passiert, wenn der Benutzer eine ungültige E-Mail-Adresse eingibt oder das Passwort nicht den vorgegebenen Kriterien entspricht.

Schritt 5: Fügen Sie relevante Anhänge hinzu

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:

Schritt 6: Lassen Sie den Testfall überprüfen

Freigeben Sie den erstellten Testfall vor der Ausführung einem Kollegen oder einem leitenden QA-Mitarbeiter. Überprüfen Sie bei der Durchsicht Folgendes:

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. Markieren Sie einen Test in jedem Schritt als „bestanden“ oder „nicht bestanden“. Erstellen Sie für jeden nicht bestandenen Schritt sofort einen Fehlerbericht 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.

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 nutzt die Komponenten und das Format der Schritte aus den früheren 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 Checkout-Prozess 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.

Testdatum: 03.09.2026

Testfall-ID: TC_CHECKOUT_003

Beschreibung: Überprüfen Sie, ob ein angemeldeter Benutzer einen Kauf mit einer gespeicherten Kreditkarte und Standardversand fertigstellen kann.

Voraussetzungen:

Zusammenfassung der Ergebnisse: Der Checkout-Flow verarbeitet den Übergang vom Warenkorb zum Versand korrekt, doch die Abwicklung der Zahlung schlägt bei gespeicherten Kreditkarten fehl. Fehler protokolliert: 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 (keine 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.

Testdatum: 05.09.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:

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, Berechtigungsgrenzen)

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 es ordnungsgemäß verweigert wird. Das erwartete Ergebnis für die meisten Schritte ist ein Block, nicht ein Erfolg.

Tester: Marcus L.

Testdatum: 08.09.2026

Testfall-ID: TC_RBAC_002

Beschreibung: Stellen Sie sicher, dass ein Benutzer mit der Rolle „Viewer“ keine Projekte erstellen, bearbeiten oder löschen kann.

Voraussetzungen:

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 eine Nachverfolgung.

ClickUp

ClickUp für 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.

Wichtigste Features von ClickUp

Limitierungen von ClickUp

Preise für ClickUp

Bewertungen und Rezensionen zu ClickUp

Was sagen echte Benutzer über ClickUp?

Hier ist, was ein G2-Rezensent dazu zu sagen hat:

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 einen klaren Überblick darüber, wer für was verantwortlich ist und wo Projekte zu jedem Zeitpunkt stehen.

TestRail

TestRail ist eine spezielle Testmanagement-Plattform für QA-Teams, die eine strukturierte Kontrolle über ihren gesamten Testprozess benötigen. Sie deckt den gesamten Zyklus vom Erstellen über das Ausführen bis hin zur Berichterstellung von Testfällen ab, wobei Ergebnisse über DevOps- und CI/CD-Integrationen eingespeist werden.

Wichtigste Features von TestRail

Limitierungen von TestRail

Preise für TestRail

Bewertungen und Rezensionen zu TestRail

Was sagen echte Benutzer über TestRail?

Hier ist, was ein G2-Rezensent dazu zu sagen hat:

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 es sehr, 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 Sprintplanung und Berichterstellung unglaublich hilfreich. In meiner täglichen Arbeit als QA-Ingenieur hat mir der Einsatz von TestRail zudem viel Zeit gespart.

Zephyr

Zephyr ist das Testmanagement-Plugin von SmartBear für Jira, das entwickelt wurde, um Testfälle direkt über die Jira-Benutzeroberfläche zu verwalten. Es unterstützt sowohl manuelle als auch automatisierte Tests und bietet leistungsstarke Funktionen für die Berichterstellung und Rückverfolgbarkeit für agile und Enterprise-Teams.

Die wichtigsten Features von Zephyr

Limitierungen von Zephyr

Preise für Zephyr

Bewertungen und Rezensionen zu Zephyr

Was sagen echte Benutzer über Zephyr?

Hier ist die Meinung eines G2-Rezensenten:

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 herausragendes Feature dieses tools ist die Möglichkeit, Testfälle als bestanden oder nicht bestanden zu markieren und Anhänge hinzuzufügen.

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 Lösungen wie Zephyr Scale oder Xray ein, um das Testfallmanagement innerhalb ihres bestehenden Jira-Setups abzuwickeln.

Wichtigste Features von Jira

Limitierungen von Jira

Jira-Preise

Jira-Bewertungen und Rezensionen

Was sagen echte Benutzer über Jira?

Hier ist, was ein G2-Rezensent dazu zu sagen hat:

Jira ist eines meiner bevorzugten digitalen Programme zur Nachverfolgung und Visualisierung der Leistung all meiner Arbeitsprojekte in Zusammenarbeit mit allen Mitgliedern meines Arbeitsteams, da es die besten virtuellen Leistungsfunktionen seiner Klasse bietet und mir so das Erreichen all meiner beruflichen Ziele erleichtert.

Häufige Fehler, die Sie beim Erstellen von Testfällen vermeiden sollten

Vermeiden Sie diese Fehler beim Verfassen von Testfällen, die deren Gesamtwirksamkeit beeinträchtigen können.

So bleiben Testfälle langfristig nützlich

Eine Testsuite bleibt zuverlässig, wenn jeder Testfall unabhängig ist, auf die Eingaben abzielt, die am ehesten zu Fehlern führen, und ausgemustert wird, sobald er kein verlässliches Ergebnis mehr liefert. Diese sechs Vorgehensweisen unterscheiden Suiten, die über Jahre hinweg Fehler aufdecken, von solchen, die bereits nach dem zweiten Sprint ignoriert werden.

Schreiben Sie unabhängige, atomare Tests

Ein Testfall sollte seinen eigenen Zustand festlegen und niemals von einer Abhängigkeit zu einem anderen Fall ausgehen, der zuvor ausgeführt wurde. 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 Fehlern, und Sie verbringen den Vormittag damit, herauszufinden, welcher Fehler tatsächlich aufgetreten ist. Wenn der 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 findet „Off-by-One“-Fehler, die bei zufälligen Eingaben übersehen werden.

Nutzen Sie Äquivalenzpartitionierung, um redundante Testfälle zu vermeiden

Gruppieren Sie Eingaben, die das System identisch behandeln soll, und testen Sie dann jeweils eine repräsentative Eingabe 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 Testfälle verdreifacht Ihren Wartungsaufwand, ohne die Testabdeckung zu erhöhen.

Trenne Testdaten von Testschritten

Wenn Sie „enter test@example.com“ fest in einen Schritt einbauen, müssen Sie diesen Schritt jedes Mal neu schreiben, wenn sich die Testumgebung ändert. Halten Sie Schritte allgemein („eine registrierte E-Mail-Adresse eingeben“) und speichern Sie die tatsächlichen Werte in einem Testdatenfeld oder einer Datei. Die gleichen Schritte lassen sich dann ohne Änderungen in der Staging-, QA- und Vorproduktionsumgebung ausführen, und das Einfügen eines neuen Datensatzes für einen Negativtest erfordert nur eine einzige 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 mehr als ein paar Mal im Monat unzuverlässig ist, sollten Sie ihn umschreiben oder entfernen. Kombinieren Sie dies mit der Fehlerdurchlassrate (Fehler, die in der Produktion gefunden wurden, die ein Testfall eigentlich hätte abfangen sollen), um zu erkennen, wo die Testabdeckung lückenhaft ist – und nicht nur, wo sie zu vielen Fehlalarmen führt.

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 diejenigen Arten von Softwaretests entlastet, die Urteilsvermögen erfordern, wie beispielsweise Usability-Tests und die Suche nach Randfällen.

So schreiben und führen Sie Testfälle in ClickUp aus

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 Space 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 aufeinanderfolgende Ausführungsschritte und erwartete Ergebnisse zu dokumentieren. Checklisten eignen sich gut für schrittweise Flows, bei denen ein Tester jede Aktion abhaken muss, während die Beschreibung Kontextinformationen wie Vorbedingungen und Testdaten enthält.

Verfolgen Sie die Ausführung und die Ergebnisse. Erstellen Sie benutzerdefinierte Status, die Ihren Test-Workflow widerspiegeln: Nicht gestartet → In Bearbeitung → Bestanden → Fehlgeschlagen → Blockiert. Wenn ein Test fehlschlägt, wandeln Sie ihn in eine Bug-Aufgabe 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 Aufgabenbeschreibung, die verknüpften Spezifikationen und Kommentare liest, einen Korrekturvorschlag verfasst und einen Pull Request zur Überprüfung eröffnet, wobei der 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 Fehlerbehebungsaufgaben zusammenzufassen. Auf diese Weise verfügen sie über den gesamten Kontext, den sie für Sprints benötigen, ohne einzelne Aufgaben durchforsten zu müssen, um sich ein Bild zu machen.

Führen Sie Testzyklen mit Ansichten durch. Verwenden Sie die nach Status gruppierte Board-Ansicht, um die Verteilung von „Bestanden“ und „Nicht bestanden“ während eines Testlaufs auf einen Blick zu sehen. Die Tabellenansicht fungiert als herkömmliche Testmatrix, wenn Sie die Ergebnisse Dutzender Testfälle ü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 herspringen zu müssen.

Kostenlose Vorlage herunterladen

Verwalten Sie Ihre Test-Workflows effektiv

Ein Testfall hat seinen Zweck erfüllt, 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 Vorbedingungen, 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 erstellen, ausführen und nachverfolgen – zusammen mit den dabei 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 haben?

Eine einzelne Anforderung kann einen oder zehn Testfälle erfordern, je nachdem, wie viele Szenarien, Randfälle und Eingabevariationen sie umfasst. Das Ziel ist es, alle realistischen Pfade abzudecken und 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 nachvollziehbar sind. Bündeln Sie nicht mehrere Aktionen und vermeiden Sie unnötige Komplexität.

Ein Testszenario legt in einer Zeile fest, was getestet werden soll („Passwortzurücksetzung überprüfen“); ein Testfall spezifiziert wie dies geschehen soll, mit Vorbedingungen, Schritten, Testdaten und erwarteten Ergebnissen. Ein Szenario umfasst in der Regel 3 bis 10 Testfälle, die den Happy Path, ungültige Eingaben und Randbedingungen abdecken. Szenarien stehen an erster Stelle und bestimmen die Abdeckungsplanung; Testfälle stehen an zweiter Stelle und bestimmen die Ausführung.

Ein positiver Testfall verwendet gültige Eingaben und erwartet einen Erfolg: Mit der richtigen E-Mail-Adresse und dem richtigen Passwort wird der Benutzer angemeldet. Ein negativer Testfall verwendet ungültige oder unerwartete Eingaben und erwartet, dass das System den Fehler korrekt behandelt: 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 und nicht in den „Happy Paths“ auftreten.

Ein Plan definiert den Umfang, den Ansatz, die Ressourcen und den Zeitplan für den gesamten Aufwand beim Testen. Eine Testsuite ist eine Sammlung von Testfällen, die für einen einzelnen Durchlauf gruppiert 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.