Testfall-Vorlage 2026: Kostenloses Format + Beispiele

Eine Testfall-Vorlage ist ein wiederverwendbares Format, um einen einzelnen Test zu dokumentieren: eine eindeutige ID, Titel, Vorbedingungen, Testdaten, nummerierte Schritte, erwartetes Ergebnis, tatsächliches Ergebnis, Status und Nachweise. Wenn du jedes Mal dieselben Felder ausfüllst, kann jede Person im Team den Test gleich ausführen, und alle kommen zum selben Urteil, ob er bestanden ist.

Unten bekommst du die Vorlage in drei Formaten, eine Erklärung zu jedem Feld, fünf ausgefüllte Beispiele und einen Weg, Screenshot-Nachweise hinzuzufügen, wenn ein Schritt fehlschlägt.

Was ist ein Testfall (und was eine Vorlage bringt)

Einfach gesagt ist ein Testfall ein kurzes Skript, mit dem du ein einzelnes Verhalten prüfst. Er sagt, wo du anfängst, was du tust, welche Daten du nutzt und was du sehen solltest. Das ISTQB-Glossar definiert ihn als Menge von Vorbedingungen, Eingaben, Aktionen, erwarteten Ergebnissen und Nachbedingungen.

Eine gemeinsame Vorlage erleichtert drei Dinge:

• Reproduzierbarkeit. Eine neue Testerin oder ein Kunde beim Abnahmetest kommt zum selben Ergebnis wie du.
• Übergabe. Ein fehlgeschlagener Testfall enthält schon das meiste, was ein Entwickler braucht.
• Audit-Trail. Status, Build und Nachweise zeigen, was getestet wurde, wann und wo.

Testfälle sind Schritt-für-Schritt-Anleitungen für Tester. Deshalb gelten dieselben Regeln wie beim Erstellen von Schritt-für-Schritt-Anleitungen mit Screenshots: eine Aktion pro Schritt und immer das erwartete Ergebnis zeigen. Die Norm für Testdokumentation ISO/IEC/IEEE 29119-3 nutzt dieselben Kernfelder, daher lässt sich dieses Format sauber auf eine formale Testfalldokumentation übertragen.

Kostenlose Testfall-Vorlage (zum Kopieren)

Alle drei Formate enthalten dieselben Felder.

Markdown-Version

Nutz sie in einem Repo, einem Wiki oder jedem Docs-as-Code-Setup. GitHubs Anleitung zum Organisieren von Informationen in Tabellen erklärt die Syntax, falls du Spalten ergänzt.

## [ID] · [Titel: das Ergebnis, das du erwartest]

| Feld | Wert |
| --- | --- |
| Anforderung | [Story- oder Ticket-ID] |
| Priorität | [Hoch, Mittel oder Niedrig] |
| Umgebung | [Build · Browser · OS] |
| Vorbedingungen | [Zustand des Systems vor Schritt 1] |
| Testdaten | [Exakte Eingaben] |
| Autor · zuletzt geprüft | [Name · JJJJ-MM-TT] |

| # | Schritt | Erwartetes Ergebnis |
| --- | --- | --- |
| 1 | [Eine Aktion] | [Was du sehen solltest] |
| 2 | [Eine Aktion] | [Was du sehen solltest] |
| 3 | [Eine Aktion] | [Was du sehen solltest] |

- **Tatsächliches Ergebnis:** [Während des Testlaufs ausfüllen]
- **Status:** Nicht ausgeführt / Bestanden / Fehlgeschlagen / Blockiert
- **Nachweise:** [Dateinamen von Screenshots, GIFs oder Logs]

Jeder Schritt bekommt sein eigenes erwartetes Ergebnis. Wenn Schritt 3 fehlschlägt, weißt du genau, wo es kaputtgegangen ist.

Version für Google Sheets oder Excel

Speichere diesen Block als test-cases.csv. In Google Sheets gehst du auf Datei > Importieren > Hochladen. In Excel nutzt du Daten > Aus Text/CSV. Du bekommst die Kopfzeile plus einen ausgefüllten Testfall.

ID,Titel,Anforderung,Priorität,Vorbedingungen,Testdaten,Schritte,Erwartetes Ergebnis,Tatsächliches Ergebnis,Status,Umgebung,Nachweise,Autor,Zuletzt geprüft
LOGIN-002,Login schlägt mit falschem Passwort fehl,AUTH-12,Hoch,"Konto ist aktiv. Nutzer ist abgemeldet.","qa.jane@example.com / Wrong-Pass-1","1. /login öffnen 2. E-Mail eingeben 3. Falsches Passwort eingeben 4. Auf Sign in klicken","4. ""Incorrect email or password."" wird angezeigt, Passwortfeld wird geleert, URL bleibt /login",,Nicht ausgeführt,"Build 2.8.1, Chrome, Windows 11",,J. Doe,2026-10-01

Dann richtest du die Tabelle ein:

1. Kopfzeile fixieren. In Sheets gehst du auf Ansicht > Fixieren > 1 Zeile. In Excel gehst du auf Ansicht > Fenster fixieren > Oberste Zeile fixieren.
2. Status als Drop-down anlegen. In Sheets markierst du die Spalte, öffnest Daten > Datenvalidierung, fügst eine Drop-down-Regel hinzu und trägst Nicht ausgeführt, Bestanden, Fehlgeschlagen und Blockiert ein (Anleitung von Google). In Excel öffnest du Daten > Datenüberprüfung, stellst Zulassen auf Liste und trägst unter Quelle Nicht ausgeführt;Bestanden;Fehlgeschlagen;Blockiert ein. Mit deutschen Regionaleinstellungen trennt Excel die Werte per Semikolon, mit englischen per Komma (Anleitung von Microsoft).
3. Status einfärben. Füg eine bedingte Formatierung hinzu: Grün für Bestanden, Rot für Fehlgeschlagen, Orange für Blockiert.
4. Ein lesbares ID-Schema nutzen. Ein Feature-Präfix plus drei Ziffern: LOGIN-001, CHECKOUT-014. Vergib eine ID nie ein zweites Mal.

Gherkin-Variante für BDD-Teams

Wenn dein Team verhaltensgetriebene Tests (BDD) schreibt, passt derselbe Testfall in das Schema Given, When, Then. Speichere ihn in einer .feature-Datei. Die Gherkin-Referenz von Cucumber listet jedes Schlüsselwort. Mit der Zeile # language: de am Dateianfang versteht Cucumber auch die deutschen Schlüsselwörter Angenommen, Wenn und Dann.

# language: de
Funktionalität: Login

  @LOGIN-002 @priority-high
  Szenario: Login schlägt mit falschem Passwort fehl
    Angenommen es gibt ein aktives Konto "qa.jane@example.com"
    Und ich bin abgemeldet
    Wenn ich die Login-Seite öffne
    Und ich mich mit dem Passwort "Wrong-Pass-1" anmelde
    Dann sehe ich die Meldung "Incorrect email or password."
    Und das Passwortfeld ist leer
    Und ich bin weiterhin auf der Login-Seite

Gherkin liest sich gut, hat aber keinen Platz für Nachweise oder Status. Halte die ID wie oben in einem Tag fest und speichere die Ergebnisse der Testläufe in deinem Testtool.

Was die einzelnen Felder eines Testfalls bedeuten

Hier steht, was du in jedes Feld schreibst, jeweils mit einem schwachen und einem starken Beispiel.

Vorbedingungen und erwartetes Ergebnis leisten die meiste Arbeit. Ohne sie liefern dieselben Schritte unterschiedliche Ergebnisse, und niemand kann sagen, ob der Test bestanden ist. Halte Testdaten in einem eigenen Feld, denn Daten ändern sich öfter als Schritte.

Testfälle schreiben in 7 Schritten

Testfälle schreibst du schneller, wenn du jedes Mal derselben Reihenfolge folgst.

1. Starte bei einer Anforderung. Wähle eine User Story, eine Zeile der Spezifikation oder einen Bugfix und notiere die ID.
2. Liste die Szenarien auf. Ein Szenario ist ein Nutzerziel, etwa „anmelden“. Deck den Happy Path, Fehlerpfade und Randfälle ab.
3. Teile jedes Szenario in Testfälle auf. Ein Testfall prüft ein Ergebnis. Aus „anmelden“ werden gültiger Login, falsches Passwort, gesperrtes Konto und leere Felder.
4. Schreib Schritte, die jeder ohne Vorwissen ausführen kann. Siehe unten.
5. Schreib erwartete Ergebnisse, die sich prüfen lassen. Siehe unten.
6. Lass den Testfall im Peer Review prüfen. Jemand, der ihn nicht geschrieben hat, führt ihn ohne Einweisung aus. Jede Rückfrage zeigt eine Lücke.
7. Pflege ihn. Aktualisiere den Testfall, wenn sich das Feature ändert, und trag das Prüfdatum ein.

Schreib Schritte, die jeder ohne Vorwissen ausführen kann

Stell dir eine Testerin vor, die gestern angefangen hat und nichts vom „offensichtlichen“ Setup weiß.

• Vorher: „Mit falschem Passwort einloggen und den Fehler prüfen.“
• Nachher: „1. /login öffnen. 2. qa.jane@example.com eingeben. 3. Wrong-Pass-1 eingeben. 4. Auf Sign in klicken.“

Nenne das genaue Bedienelement: den Button „Sign in“, nicht „absenden“. Das Setup gehört in die Vorbedingungen. Mit einer Aktion pro Schritt zeigt ein Fehlschlag auf genau einen Schritt.

Schreib erwartete Ergebnisse, die sich prüfen lassen

Zwei Personen sollten ein erwartetes Ergebnis auf dieselbe Weise prüfen. Zitiere exakten Text, nenne die URL und gib Zahlen an.

• Vorher: „Ein Fehler wird angezeigt und es funktioniert korrekt.“
• Nachher: „‚Incorrect email or password.‘ erscheint über dem Button. Das Passwortfeld ist leer. Die URL bleibt /login.“

Für visuelle Prüfungen hängst du einen annotierten Referenz-Screenshot an und schreibst „Entspricht LOGIN-002_expected.png“.

Testfall-Beispiele (ausgefüllt)

Jeder Beispiel-Testfall unten ist vollständig, du kannst ihn also direkt in deine eigene Tabelle übernehmen.

Positiver Testfall: Login mit gültigen Zugangsdaten

• ID und Priorität: LOGIN-001 · Hoch
• Vorbedingungen: Konto ist aktiv, Nutzer ist abgemeldet
• Testdaten: qa.jane@example.com, Test#Pass26

Negative Testfälle: falsches Passwort und gesperrtes Konto

Negative Testfälle prüfen, ob die App im Fehlerfall sicher reagiert.

LOGIN-002: Login schlägt mit falschem Passwort fehl (Hoch). Vorbedingungen: Konto ist aktiv, Nutzer ist abgemeldet. Testdaten: qa.jane@example.com, Wrong-Pass-1.

Die Fehlermeldung verrät nie, welches Feld falsch ist. So können Angreifer nicht herausfinden, zu welchen E-Mail-Adressen ein Konto existiert.

LOGIN-003: Konto wird nach 5 Fehlversuchen gesperrt (Hoch). Vorbedingungen: Die Sperre greift nach 5 Versuchen. Das Konto qa.lock@example.com ist aktiv. Testdaten: qa.lock@example.com, Wrong-Pass-1 (5-mal), danach das richtige Passwort Test#Pass26.

Grenzwert-Testfall: Validierung von E-Mail und Passwort

Bugs häufen sich an Grenzen. Teste deshalb jede Grenze und den nächsten Wert direkt dahinter: 7 und 8 am unteren Ende, 64 und 65 am oberen. Dieses Registrierungsformular verlangt eine gültige E-Mail-Adresse und ein Passwort mit 8 bis 64 Zeichen.

SIGNUP-007: Registrierung lehnt ungültige E-Mail und falsche Passwortlänge ab (Mittel). Vorbedingungen: Nutzer ist abgemeldet und auf /signup. Schritte: 1. Die E-Mail eingeben. 2. Ein Passwort mit der angegebenen Länge eingeben. 3. Auf Create account klicken. Einmal pro Zeile ausführen.

In einer Tabelle gibst du jeder Zeile eine eigene ID, damit ein Fehlschlag auf genau eine Eingabe zeigt.

UI- und Layout-Testfall mit Referenz-Screenshot

Bei Layout-Prüfungen ist das erwartete Ergebnis ein annotiertes Referenzbild, die sogenannte Baseline.

PRICE-004: Preisseite entspricht der freigegebenen Baseline (Mittel). Vorbedingungen: Build 2.8.1 ist live und das Fenster ist 1280 px breit. Schritte: 1. Die öffentliche Seite /pricing öffnen. 2. Die ganze Seite mit PRICE-004_baseline.png vergleichen. Erwartet: Die Seite entspricht den Markern 1 bis 3 auf der Baseline.

Nimm die Baseline als ein einziges Vollseitenbild auf, damit nichts unterhalb des sichtbaren Bereichs fehlt. Die Anleitungen für Vollseiten-Screenshots auf dem Mac und unter Windows zeigen die Optionen in Browsern und Tools.

API-Testfall: Bestellung mit Menge 0 ablehnen

API-Testfälle nutzen dieselbe Vorlage. Der Request ist der Schritt, Statuscode plus Body sind das erwartete Ergebnis.

ORDER-API-003: API lehnt eine Bestellung mit Menge 0 ab (Hoch). Vorbedingungen: ein gültiges QA-API-Token. Die SKU TEST-100 ist auf Lager.

POST /api/v1/orders
Content-Type: application/json
Authorization: Bearer <QA-Token aus dem Test-Vault>

{"sku": "TEST-100", "quantity": 0}

Erwartetes Ergebnis: Status 422 mit dem Body {"error": "quantity must be at least 1"}. Ein anschließendes GET /api/v1/orders zeigt keine neue Bestellung. Wenn die echte Antwort lang ist, füg beide Versionen in ein Tool zum Textvergleich ein, um den Unterschied zu finden.

Testfall vs. Testszenario vs. Testplan vs. Testskript

Kurz gesagt: Ein Szenario sagt, was getestet wird. Ein Testfall sagt, wie getestet wird und was als bestanden gilt. Der Plan sagt, welche Testfälle laufen, wer sie ausführt und wann.

Von den Machern dieser Seite

Genug von langweiligen Screenshots? Probier ScreenSnap Pro.

Schöne Hintergründe, professionelle Anmerkungen, GIF-Aufnahme und sofortiges Teilen in der Cloud, alles in einer App. Einmal 34 $ zahlen, für immer besitzen.

Preis und Funktionen ansehen

Visuelle Nachweise zu deinen Testfällen hinzufügen

Screenshots und kurze Aufnahmen machen einen Testfall schneller ausführbar und einen Fehlschlag schneller verständlich. Dieser Abschnitt behandelt Nachweise für einen Lauf eines Testfalls.

Referenz-Screenshots für erwartete Ergebnisse

Nimm den erwarteten Zustand einmal auf und nummeriere ihn so, dass jeder Marker zu einem Schritt passt: Marker 3 zeigt, womit du in Schritt 3 interagierst. Ein kurzer Blick, und die Testerin weiß, wo sie klicken und was sie prüfen muss.

Jeder Editor mit nummerierten Markern funktioniert. ScreenSnap Pro hat ein Zähler-Werkzeug, das Marker beim Klicken fortlaufend nummeriert, dazu Pfeile, Hervorhebungen und Text. Außerdem kannst du den Referenz-Screenshot anpinnen, sodass er über anderen Fenstern schwebt, während du den Testfall ausführst. Die Annotations-Anleitungen für den Mac und für Windows erklären die Techniken.

Das tatsächliche Ergebnis festhalten, wenn ein Schritt fehlschlägt

Wenn ein Schritt fehlschlägt, nimm sofort einen Screenshot auf, bevor du es noch einmal versuchst. Dann annotierst du ihn:

1. Zieh einen Rahmen um das falsche Ergebnis.
2. Füg einen kurzen Hinweis hinzu: „Erwartet: X. Tatsächlich: Y.“
3. Behalte Details, die beim Debuggen helfen, etwa eine Request-ID oder einen Fehlercode.
4. Leg ein deckendes Rechteck über personenbezogene Daten (siehe nächster Abschnitt).

Für die Aufnahme selbst reichen die Bordmittel: Sieh dir Apples Anleitung für Screenshots auf dem Mac und das Snipping Tool unter Windows an.

Manche Fehler haben mit Timing zu tun: ein Spinner, der nie aufhört, oder ein Button, der doppelt auslöst. Ein Standbild kann das nicht zeigen. Nimm stattdessen ein GIF mit 5 bis 10 Sekunden auf, mit den Schritten für eine GIF-Bildschirmaufnahme auf dem Mac oder unter Windows.

Für das Feld „Tatsächliches Ergebnis“ kopierst du den exakten Fehlertext, statt ihn abzutippen. OCR liest Text aus einem Screenshot aus: Nutze Live Text auf dem Mac, OCR-Software unter Windows oder ein kostenloses Tool, um Text aus einem Bild zu extrahieren.

Testdaten und personenbezogene Daten schwärzen, bevor du etwas anhängst

Nachweise landen in Tickets, Chats und Kundenberichten. Prüfe deshalb zuerst jeden Screenshot auf E-Mail-Adressen, Namen, Tokens und Kundendaten.

• Verdeck Secrets und personenbezogene Daten mit einem vollflächig gefüllten, undurchsichtigen Rechteck. Weichzeichnen und Verpixeln lassen sich rückgängig machen, wie die Anleitung zum Schwärzen von Text in Screenshots erklärt.
• Nutze Weichzeichnen oder Verpixeln nur für unkritische Details, etwa den Titel eines Browser-Tabs. Die Anleitung zum Weichzeichnen und Verpixeln auf dem Mac zeigt, wie beides funktioniert.
• Noch besser: Teste von Anfang an mit Fake-Daten, also mit E-Mail-Adressen auf example.com, vorbereiteten Seed-Konten und dem Testmodus deines Zahlungsanbieters.

Wo Nachweise hingehören

Häng die Bilddatei selbst an den Testlauf oder an das Jira-Issue an. Atlassian erklärt, wie du Dateien und Bilder zu einem Arbeitselement hinzufügst, und die Anleitung für Screenshots in Jira zeigt einen schnellen Workflow. Benenne Dateien nach Testfall und Lauf, etwa LOGIN-002_run1.png, damit sie zusammen sortiert werden.

Cloud-Links zum Teilen sind praktisch für eine schnelle Übergabe in Slack oder Teams, aber Uploads können nach einer Weile entfernt werden. Nachweise, die du für einen Audit-Trail brauchst, sollten als Datei angehängt sein.

Vom fehlgeschlagenen Testfall zum Bug-Report

Ein fehlgeschlagener Testfall ist schon fast ein fertiger Bug-Report. Übertrag die Felder und leg das Ticket an.

Zwei Dinge brauchen einen frischen Blick: eine Zusammenfassung, die den Fehler benennt, und ein Schweregrad, der die echte Auswirkung widerspiegelt. Die Anleitung zur Bug-Report-Vorlage deckt den Rest ab, mit Formaten für Jira und GitHub. Trag danach die Bug-ID im Testfall ein, damit der nächste Lauf weiß, dass ein Fix aussteht.

Häufige Fehler bei Testfällen und wie du sie behebst

• Vage Schritte. „Einstellungsseite prüfen.“ Lösung: Nenne die Seite, das Bedienelement und die Aktion.
• Mehrere Prüfungen in einem Testfall. Ein Testfall, der Login, Profilbearbeitung und Logout testet, kann aus drei Gründen fehlschlagen. Lösung: Teile ihn so auf, dass jeder Testfall ein Ergebnis hat.
• Fehlende Testdaten. „Nimm einen gültigen Nutzer“ führt zu unterschiedlichen Konten und Ergebnissen. Lösung: Liste exakte Werte auf.
• „Funktioniert korrekt“ als erwartetes Ergebnis. Daran kann kein Test scheitern. Lösung: Zitiere Text, nenne URLs und gib Zahlen an.
• Testfälle, die voneinander abhängen. Wenn CHECKOUT-005 den Warenkorb aus CHECKOUT-004 braucht, blockiert ein Fehlschlag beide. Lösung: Stell den Zustand über die Vorbedingungen oder ein Seed-Skript her.
• Veraltete erwartete Ergebnisse nach einem Redesign. Der Testfall nennt den „blauen Save-Button“, aber der Button heißt jetzt Publish. Lösung: Aktualisiere Testfälle im selben Sprint wie die UI-Änderung und nimm die Referenz-Screenshots neu auf.
• Screenshots mit echten Kundendaten. Das ist ein Datenleck. Lösung: Teste mit Seed-Daten und nutze deckende Rechtecke, wenn doch echte Daten durchrutschen.

So bleiben deine Testfälle aktuell

• Pro Release prüfen. Geh vor jedem Release die Testfälle zu geänderten Features durch und aktualisiere das Datum „Zuletzt geprüft“.
• Die Verknüpfung zur Anforderung behalten. Wenn sich eine Story ändert, findest du jeden Testfall, der sie belegt.
• Ausmustern und zusammenführen. Lösch Testfälle für entfernte Features. Führe Testfälle zusammen, die dasselbe Ergebnis mit anderen Worten prüfen.
• Für jeden durchgerutschten Bug einen Testfall ergänzen. Wenn ein Bug bei Nutzern angekommen oder in einem Bug Bash aufgetaucht ist, schreib den Testfall, der ihn gefunden hätte.
• Stabile, wiederkehrende Prüfungen automatisieren. Ein Testfall, der bei jedem Release läuft und sich selten ändert, eignet sich gut für die Automatisierung, und pixelgenaue Layout-Prüfungen gehören ins Visual Regression Testing. Manuelle Testfälle decken weiterhin ab, was Pixelvergleiche übersehen, etwa Fehlerbehandlung und ungewöhnliche Nutzerpfade.

Häufig gestellte Fragen

Wie ist ein Testfall aufgebaut?

Ein Standard-Testfall hat diese Felder: ID, Titel, Vorbedingungen, Testdaten, Schritte, erwartetes Ergebnis, tatsächliches Ergebnis, Status, Umgebung und Nachweise. Viele Teams ergänzen eine Verknüpfung zur Anforderung, eine Priorität und ein Prüfdatum.

Wie erstellt man Testfälle?

Starte bei einer Anforderung, liste ihre Szenarien auf und teile jedes Szenario in Testfälle mit je einem Ergebnis auf. Schreib Schritte, denen eine neue Testerin folgen kann, und erwartete Ergebnisse, die jeder prüfen kann. Lass sie dann im Peer Review gegenlesen.

Gibt es Tools, um Testfälle zu schreiben?

Ja. Kleine Teams kommen mit einer Tabelle oder mit Markdown-Dateien im Repo gut aus. Größere Teams nutzen Testmanagement-Tools, etwa Jira-Add-ons wie Xray oder Zephyr, TestRail oder Qase, die auch die Historie der Testläufe festhalten. Die Felder der Vorlage bleiben in allen gleich.

Wie erstelle ich einen Testfall in Excel?

Schreib die Feldnamen in Zeile 1 und fixiere sie über Ansicht > Fenster fixieren > Oberste Zeile fixieren. Leg mit Daten > Datenüberprüfung > Liste ein Drop-down für den Status an. Dann trägst du pro Zeile einen Testfall mit eindeutiger ID ein.

Kann ChatGPT Testfälle erstellen?

ChatGPT kann einen brauchbaren ersten Entwurf schreiben und Randfälle vorschlagen, die du übersehen hast, etwa leere Felder oder sehr lange Eingaben. Ein Mensch muss trotzdem jeden Schritt und jedes erwartete Ergebnis mit der echten App und der Spezifikation abgleichen, denn KI-Tools raten nur, wie sich die Software verhält. Füg nie Kundendaten, Secrets oder privaten Code in ein KI-Tool ein.

Gibt es eine Beispiel-Tabelle für Testfälle in Excel?

Ja. Speichere die CSV aus dem Abschnitt zu Google Sheets und Excel als test-cases.csv und öffne sie in Excel (über Daten > Aus Text/CSV) oder in Google Sheets. Die Datei enthält die vollständige Kopfzeile und einen ausgefüllten Login-Testfall. Füg die anderen Beispiele aus diesem Guide als weitere Zeilen hinzu.

Was ist ein Testfall, einfach erklärt?

Ein Testfall ist ein kurzes Rezept, mit dem du eine einzelne Sache in einer Software prüfst. Er sagt, wie du alles vorbereitest, was du tust und was du sehen solltest, wenn die Software funktioniert. Wenn das, was du siehst, nicht dazu passt, ist der Test fehlgeschlagen.

Testfall, Test Case oder Testcase: Was ist richtig?

Auf Deutsch ist „Testfall“ der Standardbegriff, so steht er auch im deutschsprachigen ISTQB-Glossar. Im Englischen schreibt man „test case“ in zwei Wörtern, so heißt es in ISTQB-Material, in ISO-Normen und in den meisten Tools. „Testcase“ taucht in manchem Code und in Tool-Namen auf. In Dokus und Reports schreibst du also „Testfall“ oder „test case“.

So wird jeder Testfall leicht ausführbar und leicht belegbar

Fang klein an: Kopier die Vorlage, schreib fünf Testfälle für deinen riskantesten Ablauf und häng an jeden einen annotierten Referenz-Screenshot an.

Wenn du jeden Tag Nachweise aufnimmst, vereint ScreenSnap Pro das Zähler-Werkzeug, Schwärzen mit deckenden Rechtecken, OCR, GIF-Aufnahme und Vollseiten-Aufnahmen öffentlicher Websites per URL in einer App für Mac und Windows. Es ist ein einmaliger Kauf für 34 $: 1 Lizenz für 2 Computer, Mac oder Windows. Zu den Preisen.