Salesforce UAT: ein Praxisleitfaden

Wann Sie in Salesforce einen UAT brauchen

Ein Abnahmetest beantwortet eine Frage: Kann der Fachbereich mit dieser Version von Salesforce seine Arbeit erledigen? Die Menschen, die die Arbeit machen, testen es in ihren eigenen Worten, bevor es in die Produktion geht. Sie brauchen einen in diesen Momenten.

• Ein Go-live. Die erste Sales Cloud oder Service Cloud oder der Umstieg von einem anderen CRM.
• Eine neue Cloud oder eine große Änderung. Service Cloud neben Sales Cloud, CPQ, eine neue Integration mit dem ERP oder eine neue Art, Fälle weiterzuleiten.
• Jedes Salesforce-Release. Salesforce hat drei Releases pro Jahr: Spring, Summer und Winter. Das Winter-Release kommt im Herbst und trägt die Zahl des nächsten Jahres. Jedes Release kann ändern, wie Ihre Org funktioniert, auch wenn Sie selbst nichts geändert haben.
• Die Sandbox-Preview. Sandboxes auf einer Preview-Instanz erhalten das neue Release einige Wochen vor der Produktion. Das ist Ihr Zeitfenster zum Testen. Vor jedem Release veröffentlicht Salesforce, welche Instanzen in der Preview sind und was zu tun ist, damit eine Sandbox dort bleibt. Prüfen Sie das rechtzeitig, denn eine Aktualisierung kann eine Sandbox in die Preview hinein- oder aus ihr herausbringen.

Ein Go-live braucht einen vollständigen UAT. Ein Release braucht einen kürzeren Regressionstest der Prozesse, auf die es am meisten ankommt. Mehr dazu unter Nach dem Go-live.

Die Sandbox

Testen Sie nie in der Produktion. Salesforce hat vier Sandbox-Typen. Zwei davon eignen sich für einen UAT.

Die Aktualisierung planen

Eine Aktualisierung ersetzt alles in der Sandbox durch eine neue Kopie der Produktion. Jeder Sandbox-Typ hat eine Mindestzeit zwischen zwei Aktualisierungen, und eine Full Sandbox hat die längste. Planen Sie sie also:

• Aktualisieren Sie vor dem UAT, nie währenddessen. Prüfen Sie, wann die Sandbox das nächste Mal aktualisiert werden kann.
• Deployen Sie das Release nach der Aktualisierung in die Sandbox. Arbeit, die nur in der Sandbox existierte, ist weg.
• Erledigen Sie die Schritte nach einer Aktualisierung: Lassen Sie Integrationen und Named Credentials auf Testsysteme zeigen, nicht auf die Produktion, und schalten Sie geplante Jobs ab, die nicht laufen sollen.
• Prüfen Sie die E-Mail-Zustellbarkeit. Eine neue oder aktualisierte Sandbox sendet nur System-E-Mails. Antworten auf Web-to-Lead, Freigaben und E-Mails zu Fällen brauchen mehr, aber eine Full Sandbox enthält die echten E-Mail-Adressen Ihrer Kontakte. Verwenden Sie Testadressen, bevor Sie sie freischalten.

Testdaten

Tester verlieren Stunden, wenn die Daten nicht bereit sind. Bereiten Sie sie vor dem ersten Testtag vor:

• Accounts und Kontakte für jeden Kundentyp, den Sie testen, mit dem richtigen Inhaber, der richtigen Region und dem richtigen Datensatztyp.
• Produkte und Preisbücher. Ein Produkt braucht einen Preis im Standardpreisbuch, bevor es in einem anderen Preisbuch stehen kann. Prüfen Sie, ob die Preisbücher jedes Vertriebsteams aktiv sind.
• Offene Datensätze zum Bearbeiten: Opportunities in verschiedenen Phasen, offene Fälle und Fälle kurz vor einem Meilenstein, wenn Sie Berechtigungen (Entitlements) testen.
• Keine echten personenbezogenen Daten, wo Sie es vermeiden können. Eine Full Sandbox kopiert alles, also maskieren oder anonymisieren Sie, was Tester nicht sehen müssen.

Benutzer pro Profil und Berechtigungssatz

Ein UAT beweist, dass jede Rolle ihre Arbeit erledigen kann, und nur ihre Arbeit. Legen Sie einen Testbenutzer für jede Kombination aus Profil, Rolle und Berechtigungssätzen an, die Sie testen, etwa einen Vertriebsmitarbeiter, einen Vertriebsleiter und einen Servicemitarbeiter. Jeder Tester erhält einen eigenen Benutzer, damit nie zwei Personen gleichzeitig mit demselben Benutzer arbeiten.

Nach einer Aktualisierung hängt Salesforce den Namen der Sandbox an jeden Benutzernamen und .invalid an die E-Mail-Adresse jedes Benutzers an. Setzen Sie die E-Mail-Adresse jedes Testbenutzers auf eine Adresse, die der Tester liest, sonst landen Kennwortzurücksetzungen und Freigabe-E-Mails im Nichts.

Mit Log in as sieht ein Admin Salesforce mit den Augen eines anderen Benutzers. So lässt sich ein Problem gut ansehen, das ein Tester meldet. Für den Test selbst verwenden Tester ihren eigenen Testbenutzer: Nur so wissen Sie, dass Profil und Berechtigungssätze stimmen.

Was Sie Testern über die Sandbox sagen

• Die Adresse der Sandbox. Sie enthält den Namen der Sandbox, oder sie melden sich über test.salesforce.com an. Die normale Anmeldeseite von Salesforce öffnet die Produktion.
• Ihren Benutzernamen, der mit dem Namen der Sandbox endet, und wie sie ihr Kennwort erhalten.
• Dass die Daten Testdaten sind: Nichts, was sie tun, erreicht einen echten Kunden, und nichts, was sie sehen, ist aktuell.
• Wen sie anrufen, wenn sie sich nicht anmelden können, bevor sie einen ganzen Vormittag verlieren.

In UAT StudioJeder Tester erhält eine Test role und einen Test account, oben in seinen Tests angezeigt als Log in as …. Die Notes for testers enthalten die Adresse der Sandbox, Testpostfächer und wen man anruft.

Testfälle aus User Stories und Prozessen

Gehen Sie von den Prozessen des Fachbereichs aus, nicht von den Objekten in Salesforce. Zwei Prozesse decken den größten Teil eines Salesforce UAT ab:

• Lead to Cash. Ein Lead kommt über Web-to-Lead herein, wird zugewiesen und konvertiert. Die Opportunity erhält Produkte aus dem Preisbuch, ein Angebot wird erstellt und freigegeben, der Deal wird gewonnen, und der Auftrag oder Vertrag geht an das nächste Team oder System.
• Case Management. Ein Fall kommt über E-Mail-to-Case oder das Portal herein, wird an die richtige Warteschlange oder den richtigen Mitarbeiter weitergeleitet, folgt seiner Berechtigung und seinen Meilensteinen, wird mit einem Knowledge-Artikel gelöst, bei Bedarf eskaliert und geschlossen.

Teilen Sie jeden Prozess in Testfälle mit je einem Geschäftsszenario auf, etwa Lead mit einem bestehenden Account konvertieren. Prüfen Sie dann, ob jede User Story im Umfang mindestens einen Testfall hat.

Schritte, die Tester aus dem Fachbereich verstehen

Schreiben Sie jeden Schritt als Aktion und erwartetes Ergebnis, in den Worten des Testers. Fügen Sie Testdaten hinzu, wo es darauf ankommt. Ein Tester sollte nie raten müssen, ob ein Schritt bestanden ist.

Priorität und Risiko

Nicht jeder Testfall ist gleich wichtig. Kennzeichnen Sie jeden mit Must, Should oder Could: Must ist, was am ersten Tag funktionieren muss, etwa ein Angebot erstellen oder einen Fall weiterleiten. Ergänzen Sie das Risiko: was es kostet, wenn das nach dem Go-live schiefgeht. Tester beginnen mit Must und hohem Risiko, damit die wichtigen Tests erledigt sind, auch wenn die Zeit knapp wird.

Nehmen Sie auch die Fehlerfälle auf: ein leer gelassenes Pflichtfeld, ein Rabatt über dem Limit, ein Benutzer, der einen Datensatz nicht sehen dürfte.

In UAT StudioImportieren Sie Ihre Testfälle aus Excel mit den Spalten Priority und Risk, oder starten Sie mit den Salesforce-Skripten aus der Vorlagenbibliothek, einem Add-on zu jedem bezahlten Paket. Tester sehen ihre Must-Testfälle zuerst.

Tester

Wählen Sie Menschen, die die Arbeit jeden Tag machen: Vertriebsmitarbeiter, Servicemitarbeiter und ihre Vorgesetzten für Freigaben, Prognosen und Berichte. Nehmen Sie Tester aus jedem Team und jedem Land, das Salesforce nutzt, denn ihre Prozesse und Preisbücher unterscheiden sich.

Wie viel Zeit

Fragen Sie die Zeit pro Tester an, nicht pro Team, und stimmen Sie sie mit dessen Vorgesetztem ab. Planen Sie die Skripte so, dass jeder Tester weiß, wie viel zu tun ist. Halten Sie Zeit für Retests nach den Fixes frei. Tester, die nebenbei noch Anrufe annehmen oder Kunden besuchen, werden nicht fertig.

Ein Kick-off

Beginnen Sie mit einem kurzen Kick-off: warum ihr Test wichtig ist, wie man sich bei der Sandbox anmeldet, wie man ein Ergebnis erfasst und wie man ein Issue meldet. Lassen Sie jeden Tester sich während des Kick-offs einmal anmelden. Die meisten Probleme mit Benutzern und Kennwörtern zeigen sich dort, nicht am Testtag.

Ein Testtag oder eine Woche

• Ein Testtag, in einem Raum oder einem Call, schafft Fokus und schnelle Antworten. Er passt zu einem kleinen Umfang und zu Testern, die schwer länger freizustellen sind.
• Über eine Woche verteilt, in Blöcken von einigen Stunden, bleibt zwischen den Blöcken Raum für Fixes und Retests. Das passt zu einem Go-live mit vielen Prozessen.

So oder so: Legen Sie jeden Tag eine feste Zeit für die Triage fest.

Während des UAT

Issues erfassen

Ein gutes Issue lässt sich ohne Meeting beheben. Bitten Sie Tester um:

• Den Schritt, was sie erwartet haben und was stattdessen passiert ist.
• Einen Screenshot der Seite.
• Den Link zum Datensatz. Er steht in der Adressleiste des Browsers und führt den Entwickler direkt zur Opportunity oder zum Fall, bei dem es schiefging.
• Den Benutzer, mit dem sie getestet haben, damit das Team weiß, welches Profil und welche Berechtigungssätze verwendet wurden.

In UAT StudioDie Browsererweiterung für Chrome und Edge zeigt die Tests in einem Seitenbereich neben Salesforce. Ein fehlgeschlagener Schritt nimmt den Screenshot, den Link zum Datensatz und die Fehlermeldungen der Seite mit. Ein Issue zeigt den Datensatz als Link, Sandbox inklusive.

Triage

Gehen Sie die neuen Issues jeden Tag durch, Fachbereich und Salesforce-Team gemeinsam. Geben Sie jedem einen Schweregrad und jemanden, der es behebt, und entscheiden Sie:

• Beheben: ein echtes Problem, behoben in diesem Release.
• Ablehnen: Salesforce funktioniert wie vorgesehen, oder der Test war falsch.
• Change Request: ein Wunsch, kein Fehler. Er kommt auf das Backlog, nicht in dieses Release.

Retest

Wenn ein Fix in die Sandbox deployt ist, testet der Tester, der das Issue gefunden hat, den Schritt erneut. Notieren Sie, auf welchem Build jeder Retest durchgeführt wurde. Testen Sie nach einem großen Fix auch die Prozesse drumherum erneut.

Täglicher Status

Senden Sie dem Lenkungsausschuss jeden Tag einen kurzen Status: Fortschritt gegenüber dem Plan, offene Issues nach Schweregrad und was blockiert. Bleiben Sie bei den Fakten. Keine Überraschungen im go/no-go-Meeting.

In UAT StudioDie Triage läuft auf einem geteilten Bildschirm mit Fix, Reject und Change request. Ready for retest schickt dem Retester eine E-Mail. Eine tägliche Übersicht per E-Mail oder in Microsoft Teams zeigt die Ergebnisse und Issues des Vortags.

Abnahme und go/no-go

Der UAT endet mit einer Entscheidung des Fachbereichs. Vereinbaren Sie die Ausgangskriterien vor dem ersten Testtag, damit am Ende niemand darüber streitet:

• Kein Critical-Issue ist offen.
• Jeder Must-Testfall ist bestanden.
• Jedes offene High-Issue hat einen Workaround oder einen Termin für den Fix, den der Fachbereich akzeptiert.
• Jeder Testfall im Umfang hat ein Ergebnis.

Wer unterschreibt

Der Verantwortliche jedes Prozesses nimmt ab, etwa der Vertriebsleiter für Lead to Cash und die Leitung des Kundenservice für Case Management. Sie wählen: abgenommen, abgenommen mit Auflagen oder abgelehnt. Notieren Sie jede Auflage: wer sie erledigt und bis wann. Danach entscheidet der Lenkungsausschuss über den Go-live.

Was in den Bericht gehört

• Was im Umfang war und was nicht getestet wurde.
• Die Ergebnisse pro Prozess oder Team und pro Priorität.
• Die getestete Sandbox, das Release und der Build.
• Die offenen Issues nach Schweregrad, mit der Entscheidung zu jedem.
• Die Abnahmen mit ihren Auflagen und die bekannten Risiken für die ersten Wochen.

In UAT StudioAbnahme pro Gruppe: Accepted, Accepted with conditions oder Rejected. Standardmäßig kann niemand abnehmen, solange ein Critical-Issue offen ist. Der go/no-go-Bericht ist als PDF oder als Folien fertig, sobald das letzte Ergebnis vorliegt.

Eine Regressionsrunde für jedes Salesforce-Release

Nach dem Go-live kommen die Releases weiter: drei pro Jahr. Jedes kann eine Seite, einen Flow oder eine Berechtigung ändern. Ihre UAT-Testfälle sind der beste Regressionstest, den Sie haben, denn sie beschreiben genau, was der Fachbereich abgenommen hat.

• Bewahren Sie die Testfälle nach dem Go-live auf, mit ihren Schritten, Testdaten und erwarteten Ergebnissen.
• Lesen Sie die Release Notes des kommenden Releases und prüfen Sie, welche Funktionen automatisch für Sie eingeschaltet werden.
• Prüfen Sie, ob Ihre UAT-Sandbox in der Sandbox-Preview ist, und planen Sie die Runde im Preview-Zeitfenster.
• Testen Sie die Must-Testfälle erneut, und Should, wenn Zeit bleibt, mit einigen Testern aus dem Fachbereich.
• Erfassen Sie Issues wie im UAT und beheben Sie sie, bevor das Release die Produktion erreicht.

In UAT StudioWählen Sie Salesforce als CRM des Projekts. Die Projektseite zeigt dann die kommenden Salesforce-Releases, mit dem Datum der Sandbox-Preview, dem Datum der Produktion und den Release Notes. Start a regression round kopiert die gewählten Testfälle: Must and Should, Only Must oder All test cases in scope.

Kostenlos nutzbar

Alles, was vor, während und nach dem UAT zu regeln ist, finden Sie in der UAT-Checkliste für einen CRM-Go-live, auch als kostenlose Excel-Datei. Was UAT Studio für einen Salesforce UAT leistet, sehen Sie unter Salesforce UAT.

Salesforce, Sales Cloud und Service Cloud sind Marken von Salesforce, Inc. UAT Studio ist nicht mit Salesforce verbunden und wird nicht von Salesforce unterstützt.