Testfälle schreiben, die Tester aus dem Fachbereich verstehen

Warum Tester aus dem Fachbereich andere Testfälle brauchen

Einen Systemtest machen Personen, die das System gebaut haben oder es gut kennen. Einen Abnahmetest machen Personen, die es nutzen: Sie kennen die Arbeit, nicht die Konfiguration. Sie wissen nicht, welches Feld neu ist, welcher Flow im Hintergrund läuft oder was der Entwickler gemeint hat.

Ein UAT-Testfall muss also für jemanden funktionieren, der:

• den Geschäftsprozess auswendig kennt, aber nicht die neuen Bildschirme;
• ein paar Stunden zwischen anderer Arbeit hat, nicht eine Woche;
• nie raten sollte, ob ein Schritt bestanden oder fehlgeschlagen ist;
• anhält und wartet, wenn ein Schritt unklar ist, und dabei Zeit verliert.

Jede Stunde, die Sie in klare Testfälle stecken, spart an den Testtagen viele Stunden: weniger Fragen, weniger Issues, die sich als Missverständnisse herausstellen, und Ergebnisse, denen Sie beim go/no-go vertrauen können.

Aus User Stories und Prozessen

Testfälle kommen aus zwei Quellen, und Sie brauchen beide.

User Stories und ihre Akzeptanzkriterien

Eine User Story sagt, was jemand tun will und warum: Als Vertriebsmitarbeiter möchte ich einen qualifizierten Lead konvertieren, damit ich einen Account, einen Kontakt und eine Opportunity erhalte. Ihre Akzeptanzkriterien sagen, wann sie fertig ist. Jedes Akzeptanzkriterium ist ein Kandidat für einen Schritt oder einen Testfall.

Prüfen Sie die Abdeckung: Jede User Story im Umfang braucht mindestens einen Testfall. Eine Story ohne Testfall ist eine Lücke, und Lücken werden in der Produktion gefunden.

Geschäftsprozesse, durchgängig

User Stories werden für die Entwickler klein geschnitten. Der Fachbereich arbeitet in Prozessen, die viele Stories durchlaufen: Lead to Cash, Quote to Order, Case Management von der E-Mail bis zur Lösung. Eine Story kann für sich bestehen, während der Prozess an der Übergabe zwischen zwei Teams bricht.

Ergänzen Sie daher End-to-End-Testfälle, die einen Prozess von Anfang bis Ende über alle Rollen hinweg verfolgen: Der Vertriebsmitarbeiter erstellt das Angebot, der Vorgesetzte gibt es frei, der Auftrag geht an die Buchhaltung. Das sind oft die Testfälle, die für den Fachbereich am meisten zählen.

In UAT StudioLesen Sie die User Stories aus Jira oder Azure DevOps auf der Karte User stories ein und haken Sie Only stories without test cases an, um die Lücken zu sehen. Mit dem Modul AI test design schlägt KI Testfälle aus Ihren Stories oder aus einer Prozessbeschreibung vor, auch mit dem eigenen Modell Ihres Unternehmens. Nichts wird zum Testfall, bevor Sie es freigeben. Ohne das Modul liefert Prepare with your own AI einen Prompt, den Sie in die KI Ihres Unternehmens einfügen; mit [CHECK] markierte Schritte sind Annahmen, die Sie prüfen müssen.

Ein Ziel pro Testfall

Ein Testfall testet ein Geschäftsszenario, mit einem Ziel. Sein Titel sagt in den Worten des Fachbereichs, was der Tester erreicht:

• Einen Lead mit bestehendem Account konvertieren
• Ein Angebot mit einem Rabatt über 20% freigeben
• Eine E-Mail eines bekannten Kunden in die richtige Warteschlange leiten

Nicht Das Lead-Objekt testen und nicht Leads, Opportunities und Angebote. Hat ein Testfall mehrere Ziele, blockiert ein Fehler alle, und das Ergebnis sagt wenig: Was ist fehlgeschlagen, und was funktioniert noch?

Wie groß ist ein Testfall?

In der Regel hat ein Testfall drei bis fünfzehn Schritte und dauert für einen Tester fünf bis zwanzig Minuten. Ist er deutlich länger, hat er wahrscheinlich mehr als ein Ziel: Teilen Sie ihn. Ist er deutlich kürzer, gehört er vielleicht zu einem benachbarten Testfall.

End-to-End-Testfälle sind die Ausnahme. Sie verfolgen einen ganzen Prozess und dürfen länger sein. Behalten Sie sie, aber sorgen Sie dafür, dass jeder Teil des Prozesses auch einen eigenen kürzeren Testfall hat, damit sich ein Fehler leicht zuordnen lässt.

Schritte mit einem erwarteten Ergebnis

Jeder Schritt hat zwei Teile: eine Aktion (was der Tester tut) und ein erwartetes Ergebnis (was passieren soll). Das erwartete Ergebnis macht einen Schritt testbar. Ohne es entscheidet der Tester, was gut genug ist, und zwei Tester entscheiden unterschiedlich.

Die Aktion schreiben

• Eine Aktion pro Schritt. Öffnen Sie den Lead und klicken Sie auf Convert ist in Ordnung; fünf Klicks in einem Schritt nicht.
• Beginnen Sie mit einem Verb: öffnen, klicken, ausfüllen, auswählen, speichern.
• Verwenden Sie die Labels so, wie sie auf dem Bildschirm stehen, fett oder in Anführungszeichen.
• Sagen Sie, was zu tun ist, nicht wie das System intern funktioniert. Speichern Sie das Angebot, nicht lösen Sie den Freigabe-Flow aus.

Das erwartete Ergebnis schreiben

• Sagen Sie, was der Tester sieht: eine Meldung, einen Wert in einem Feld, einen neuen Datensatz, einen Status.
• Seien Sie konkret. Die Opportunity ist in der Phase Qualification, nicht es funktioniert.
• Nennen Sie, was nicht passieren soll, wenn es darauf ankommt: Es wird kein zweiter Account angelegt.
• Bei Dingen, die das System selbst erledigt, sagen Sie, wo man nachsehen soll: Der Fall erscheint innerhalb einer Minute in der Warteschlange Benelux Support.

Testdaten und Rollen

Testdaten

Tester verlieren mit der Suche nach Daten mehr Zeit als mit jedem anderen Teil eines UAT. Nehmen Sie die Daten überall dort in den Testfall auf, wo es darauf ankommt: welcher Kunde, welches Produkt, welche Preisliste oder welches Preisbuch, welcher Betrag. Bereiten Sie diese Daten vor dem ersten Testtag in der Testumgebung vor.

• Verwenden Sie Namen, die eindeutig Testdaten sind, etwa Jansen Logistics (test).
• Geben Sie jedem Tester eigene Datensätze, wenn er Daten ändert, damit nicht zwei Personen dieselbe Opportunity bearbeiten.
• Ergänzen Sie Grenzwerte: einen Rabatt knapp unter und knapp über dem Limit, ein leeres Pflichtfeld.
• Verwenden Sie keine echten personenbezogenen Daten von Kunden, wo Sie es vermeiden können.

Rollen

In einem CRM hängt, was ein Benutzer sehen und tun kann, von seiner Rolle ab: einem Profil und Berechtigungssätzen in Salesforce, Sicherheitsrollen und einer Unternehmenseinheit in Dynamics 365. Ein UAT weist nach, dass jede Rolle ihre Arbeit erledigen kann, und nur ihre Arbeit. Deshalb sagt jeder Testfall, welche Rolle ihn testet, und der Tester meldet sich mit einem Testbenutzer an, der genau diese Rolle hat.

Testen Sie nie mit einem Administrator. Ein Administrator sieht alles und darf alles, sodass die Probleme, die ein UAT finden soll, verborgen bleiben.

In UAT StudioJeder Schritt hat eine Aktion, ein erwartetes Ergebnis und optional Testdaten. Jeder Tester erhält eine Test role und einen Test account, oben in seinen Tests angezeigt als Log in as …, und die Rolle steht bei jedem Issue, das er erfasst, neben seinem Namen.

Priorität und Risiko

Es ist nie genug Zeit, um alles gleich gründlich zu testen. Kennzeichnen Sie jeden Testfall so, dass die wichtigen zuerst getestet und auch dann abgeschlossen werden, wenn die Zeit knapp wird.

Ergänzen Sie das Risiko: was es kostet, wenn das nach dem Go-live schiefgeht. Ein falscher Preis auf einer Rechnung ist ein hohes Risiko; ein falsches Label in einem Bericht ein niedriges. Innerhalb derselben Priorität beginnen Tester mit hohem Risiko.

Seien Sie streng mit Must. Ist die Hälfte der Testfälle Must, bedeutet das Label nichts: Reservieren Sie es für das, worauf der Fachbereich nicht verzichten kann. Stimmen Sie die Prioritäten mit den Prozessverantwortlichen ab: Sie entscheiden auch beim go/no-go mit, wo nicht bestandene Must-Testfälle am meisten zählen.

In UAT StudioSetzen Sie Priority (Must, Should, Could) und Risk (High, Medium, Low) im Editor oder beim Import in einer Spalte. Werte anderer Tools werden ebenfalls gelesen: Critical und High werden zu Must, Medium und Normal zu Should, Low zu Could. Tester sehen ihre Must-Testfälle zuerst, innerhalb jeder Priorität mit hohem Risiko zuerst.

Ein Beispiel

Testfall 12: Ein Angebot mit einem Rabatt über 20% freigeben

Priorität Must, Risiko High. User Story CRM-118. Rolle: Vertriebsmitarbeiter (Schritte 1 bis 3) und Vertriebsleiter (Schritte 4 und 5).

Beachten Sie, was es funktionieren lässt: ein Ziel im Titel, eine Aktion pro Schritt, ein erwartetes Ergebnis, das ein Tester prüfen kann, die genannten Daten und die Rolle, und ein Fehlerfall in Schritt 3. Ergänzen Sie einen zweiten Testfall für einen Rabatt unter dem Limit, der keine Freigabe brauchen sollte.

Häufige Fehler

• Kein erwartetes Ergebnis oder funktioniert wie erwartet. Der Tester muss raten, was erwartet wurde.
• Technische Sprache. Feldnamen aus der Datenbank, Objektnamen oder prüfen, ob der Trigger auslöst. Verwenden Sie die Begriffe auf dem Bildschirm.
• Zu viele Ziele in einem Testfall. Ein Fehler blockiert den Rest, und das Ergebnis sagt Ihnen wenig.
• Nur der Gutfall. Ergänzen Sie ein leer gelassenes Pflichtfeld, einen Wert über einem Limit, einen Benutzer, der einen Datensatz nicht sehen dürfte.
• Fehlende Testdaten. Öffnen Sie eine Opportunity: welche? In welcher Phase, mit welchen Produkten?
• Keine Rolle. Der Tester nutzt irgendein Konto, das er hat, oft eines mit zu vielen Rechten.
• Aus dem Systemtest kopiert. Für Entwickler geschrieben, mit Schritten, denen Tester aus dem Fachbereich nicht folgen können.
• Alles ist Must. Dann ist nichts Must, und die wichtigen Tests werden nicht zuerst gemacht.
• Einmal geschrieben, nie gelesen. Skripte, die vor den Testtagen niemand geprüft hat, sind voller alter Labels und falscher Menüs.

Lassen Sie einen Key User sie prüfen

Bitten Sie vor den Testtagen einen Key User aus dem Fachbereich, die Testfälle zu lesen und zwei oder drei davon in der Testumgebung auszuprobieren. Er findet, was der Verfasser nicht sieht: einen Schritt, der Wissen voraussetzt, ein geändertes Label, einen Prozess, der in einem anderen Land anders läuft.

Prüfen Sie gleichzeitig, dass jede User Story im Umfang einen Testfall hat, dass jede Rolle im Umfang etwas testet und dass die Testdaten vorhanden sind. Behalten Sie die Testfälle nach dem Go-live: Sie sind Ihr Regressionstest für das nächste CRM-Release.

In UAT StudioImportieren Sie Testfälle aus Excel, Azure DevOps, Jira mit Xray oder Zephyr Scale oder TestRail, oder schreiben Sie sie im Editor. Die Vorlagenbibliothek, ein Add-on zu jedem bezahlten Paket, enthält fertige Skripte für Salesforce und Dynamics 365, die Sie an Ihr eigenes Setup anpassen.

Kostenlos nutzbar

Für alles andere, was vor, während und nach dem UAT zu regeln ist, siehe die UAT-Checkliste für einen CRM-Go-live, ebenfalls als kostenlose Excel-Datei.