Dynamics 365 UAT: ein Praxisleitfaden

Wann Sie in Dynamics 365 einen UAT brauchen

Ein Abnahmetest beantwortet eine Frage: Kann der Fachbereich mit dieser Version von Dynamics 365 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. Das erste Dynamics 365 Sales oder Customer Service oder der Umstieg von einem anderen CRM.
• Eine neue App oder ein neues Modul. Customer Service neben Sales, eine neue modellgesteuerte App für ein Team, ein Kundenportal oder Copilot-Funktionen, die Sie einschalten.
• Eine große Änderung. Eine neue Integration mit dem ERP oder eine neue Art, Fälle weiterzuleiten.
• Die Updates von Microsoft. Microsoft bündelt Änderungen an Dynamics 365 nicht mehr in zwei Releasewellen pro Jahr. Neue Funktionen und Änderungen kommen das ganze Jahr über. Die Releasepläne wurden im Oktober 2026 archiviert; was kommt, steht jetzt in der Microsoft-Roadmap unter aka.ms/AIatWorkRoadmap. Jedes Update kann ändern, wie Ihr System funktioniert, auch wenn Sie selbst nichts geändert haben.

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

Umgebungen

Testen Sie nie in der Produktion. Im Power Platform Admin Center hat jede Umgebung einen Typ. Für einen UAT brauchen Sie eine Sandbox.

Eine Kopie der Produktion

Am nächsten an der Realität kommen Sie mit einer Kopie der Produktion in einer Sandbox-Umgebung. Wenn Sie eine Umgebung kopieren, wählen Sie, was mitkommt:

• Alles: die Anpassungen, das Schema und alle Daten. Am nächsten an der Produktion, enthält aber echte Kundendaten und jeden Datensatz, den Ihre Benutzer angelegt haben.
• Nur Anpassungen und Schemas: die Konfiguration ohne die Daten. Ihre eigenen Testdaten laden Sie danach.

Eine Kopie ersetzt, was in der Zielumgebung ist, also erstellen Sie sie vor dem UAT, nie währenddessen. Lassen Sie danach Integrationen und Power-Automate-Flows auf Testsysteme zeigen, nicht auf die Produktion, prüfen Sie die Postfächer und nehmen Sie die Umgebung aus dem Verwaltungsmodus, wenn sie bereit ist.

Lösungen und der Build

Die Änderungen des Projekts gelangen als Lösungen in die UAT-Umgebung. Importieren Sie sie als verwaltete Lösungen, über eine Pipeline, wenn Sie eine haben, damit die UAT-Umgebung genau das erhält, was die Produktion später erhält.

• Vereinbaren Sie, wann Lösungen importiert werden, während weiter getestet wird, zum Beispiel einmal am Tag nach der Triage. Ein Import mitten in einem Test kann den Bildschirm unter den Händen eines Testers verändern.
• Notieren Sie, welche Lösungen und Versionen in der UAT-Umgebung sind. Die Versionsnummer einer Lösung ist der Build, den Sie testen, und jedes Issue und jeder Retest gehört zu einem Build.

Testdaten

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

• Firmen und Kontakte für jeden Kundentyp, den Sie testen, mit dem richtigen Besitzer und der richtigen Unternehmenseinheit.
• Produkte und Preislisten. Ein Produkt braucht ein Preislistenelement, bevor es zum richtigen Preis hinzugefügt werden kann, und es muss veröffentlicht sein, bevor Vertriebsmitarbeiter es verwenden können. Prüfen Sie, ob die Preisliste jedes Vertriebsteams vorhanden ist.
• Warteschlangen, SLAs und Wissensartikel für Customer Service: die Warteschlangen, an die Fälle weitergeleitet werden, aktive SLAs und veröffentlichte Artikel, die gefunden werden sollen.
• Offene Datensätze zum Bearbeiten: Leads, Verkaufschancen in verschiedenen Phasen und offene Fälle.
• Keine echten personenbezogenen Daten, wo Sie es vermeiden können. Eine Kopie mit Alles enthält sie alle, also maskieren oder anonymisieren Sie, was Tester nicht sehen müssen.

Sicherheitsrollen, Unternehmenseinheiten und Benutzer pro Rolle

Ein UAT beweist, dass jede Rolle ihre Arbeit erledigen kann, und nur ihre Arbeit. In Dynamics 365 hängt das von den Sicherheitsrollen, der Unternehmenseinheit und den Teams eines Benutzers ab. Auch Apps werden über Sicherheitsrollen freigegeben: Ohne die richtige Rolle sieht ein Benutzer die App nicht einmal.

• Listen Sie die Rollen auf, die Sie testen, etwa einen Vertriebsmitarbeiter, einen Vertriebsleiter, einen Servicemitarbeiter und einen Service-Supervisor, jeweils mit ihrer Unternehmenseinheit.
• Geben Sie jedem Tester in der UAT-Umgebung einen Benutzer mit genau dieser Rolle. Jeder Benutzer braucht eine Lizenz, auch in einer Sandbox.
• Wenn eine Person mehrere Rollen testet, verwenden Sie pro Rolle einen eigenen Testbenutzer, oder wechseln Sie die Rolle zwischen den Tests und notieren Sie, welche verwendet wurde.
• Testen Sie nie mit der Rolle Systemadministrator. Sie sieht alles und darf alles und verdeckt damit genau die Probleme, die ein UAT finden soll.

Was Sie Testern über die Umgebung sagen

• Die Adresse der UAT-Umgebung. Das übliche Lesezeichen öffnet die Produktion.
• Welche App sie öffnen, etwa Sales Hub oder Customer Service-Arbeitsbereich, und mit welchem Konto sie sich anmelden.
• 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 oder die App nicht sehen.

In UAT StudioJeder Tester erhält eine Test role, etwa die Sicherheitsrolle, und einen Test account, oben in seinen Tests angezeigt als Log in as …. Die Notes for testers enthalten die Adresse der Umgebung, Testpostfächer und wen man anruft. Tester melden sich bei UAT Studio mit einem Code per E-Mail an oder mit Sign in with Microsoft.

Testfälle aus User Stories und Prozessen

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

• Vom Lead über die Verkaufschance zum Angebot. Ein Lead kommt herein und wird zu einer Firma, einem Kontakt und einer Verkaufschance qualifiziert. Die Verkaufschance folgt dem Geschäftsprozessflow und erhält Produkte aus der Preisliste, ein Angebot wird erstellt, freigegeben und aktiviert, und der Deal wird gewonnen und geht an das nächste Team oder System.
• Fallverwaltung. Ein Fall kommt per E-Mail oder über das Portal herein, wird an die richtige Warteschlange oder den richtigen Mitarbeiter weitergeleitet, folgt seinem SLA, wird mit einem Wissensartikel beantwortet, bei Bedarf eskaliert und schließlich gelöst.

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

Geschäftsprozessflows

Ein Geschäftsprozessflow führt Benutzer durch Phasen, mit Schritten, die vor der nächsten Phase erforderlich sein können. Testen Sie ihn so, wie ein Benutzer ihn nutzt:

• Jede Phase und was passiert, wenn ein erforderlicher Schritt leer ist.
• Jede Verzweigung und jede Rolle: Ein Flow kann nur für bestimmte Sicherheitsrollen aktiviert sein.

Weiterleitung, SLAs und Wissen

Im Customer Service passiert viel Arbeit ohne einen Klick. Testen Sie, was das System von selbst tun soll: Eine E-Mail wird zu einem Fall für die richtige Firma, der Fall landet in der richtigen Warteschlange, das SLA zeigt die richtige Zeit und warnt, bevor sie abläuft, und der Mitarbeiter findet den richtigen Wissensartikel.

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 in einer anderen Unternehmenseinheit, der einen Datensatz nicht sehen dürfte.

In UAT StudioImportieren Sie Ihre Testfälle aus Excel mit den Spalten Priority und Risk, lesen Sie sie aus Azure DevOps Test Plans ein, oder starten Sie mit den Dynamics-365-Skripten aus der Vorlagenbibliothek, einem Add-on zu jedem bezahlten Paket. Mit AI test design schlägt KI Testfälle aus Ihren User Stories in Azure DevOps vor, auch mit dem eigenen Modell Ihres Unternehmens, etwa Microsoft Foundry / Azure OpenAI. Nichts wird zum Testfall, bevor Sie es freigeben.

Tester

Wählen Sie Menschen, die die Arbeit jeden Tag machen: Account Manager, Servicemitarbeiter und ihre Vorgesetzten für Freigaben, Warteschlangen und Dashboards. Nehmen Sie Tester aus jedem Team und jedem Land, das Dynamics 365 nutzt, denn ihre Prozesse, Unternehmenseinheiten und Preislisten unterscheiden sich.

Wie viel Zeit

Stimmen Sie die Zeit pro Tester mit dessen Vorgesetztem ab und halten Sie Zeit für Retests 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 die UAT-Umgebung öffnet, wie man ein Ergebnis erfasst und wie man ein Issue meldet. Lassen Sie jeden Tester sich während des Kick-offs einmal anmelden und die App öffnen. Die meisten Probleme mit Lizenzen, Rollen und der falschen Umgebung zeigen sich dort, nicht am Testtag.

Ein Testtag oder eine Woche

Ein Testtag schafft Fokus und schnelle Antworten und passt zu einem kleinen Umfang. Eine Woche in Blöcken von einigen Stunden lässt Raum für neue Builds und Retests und 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, mit der Fehlermeldung, falls es eine gab.
• Den Link zum Datensatz. Er steht in der Adressleiste des Browsers und führt den Berater direkt zur Verkaufschance oder zum Fall, bei dem es schiefging.
• Den Benutzer und die Sicherheitsrolle, mit denen sie getestet haben.

In UAT StudioDie Browsererweiterung für Chrome und Edge zeigt die Tests in einem Seitenbereich neben Dynamics 365. Ein fehlgeschlagener Schritt nimmt den Screenshot, den Link zum Datensatz und die Fehlermeldungen der Seite mit. Die Rolle des Testers steht im Issue neben seinem Namen.

Triage

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

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

Senden Sie die zu behebenden Issues an die Entwickler, oft in Azure DevOps, mit dem Screenshot und dem Link zum Datensatz.

Retest

Wenn der Fix in einem neuen Build in der UAT-Umgebung 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. Keine Überraschungen im go/no-go-Meeting.

In UAT StudioDie Triage läuft auf einem geteilten Bildschirm mit Fix, Reject und Change request. Ein Issue wird zu einem Bug-Work-Item in Azure DevOps; wenn es dort erledigt ist, steht das Issue auf Ready for retest, und der Tester erhält eine E-Mail. Jede Runde behält ihr Release, ihren Build und ihre Umgebung. Microsoft Teams erhält neue Issues, Runden und Abnahmen in einem Kanal.

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 bis Angebot und die Leitung des Kundenservice für die Fallverwaltung. 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 Umgebung, die Lösungen 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.

Regressionsrunden in festem Rhythmus

Nach dem Go-live kommen die Updates weiter, das ganze Jahr über, und jedes kann ein Formular, einen Flow oder eine Berechtigung ändern. Ihre UAT-Testfälle sind der beste Regressionstest, den Sie haben: Sie beschreiben genau, was der Fachbereich abgenommen hat.

• Wählen Sie einen Rhythmus, zum Beispiel eine Regressionsrunde jeden Monat oder jedes Quartal, und tragen Sie die Termine schon jetzt in den Kalender der Tester ein.
• Lesen Sie vor jeder Runde die Microsoft-Roadmap und die Mitteilungen für Ihre Admins, und notieren Sie, welche Änderungen Ihre Prozesse berühren.
• Probieren Sie Funktionen in der Vorschau oder im Vorabzugriff zuerst in einer Sandbox-Umgebung aus, bevor sie Ihre Benutzer erreichen.
• 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 die Änderung Ihre Benutzer erreicht.

In UAT StudioWählen Sie Dynamics 365 als CRM des Projekts. Start a regression round kopiert die gewählten Testfälle eines früheren UAT, mit ihren Schritten, Testdaten und erwarteten Ergebnissen: 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 Dynamics 365 UAT leistet, sehen Sie unter Dynamics 365 UAT.

Microsoft, Dynamics 365, Power Platform, Azure DevOps und Microsoft Teams sind Marken der Microsoft-Unternehmensgruppe. UAT Studio ist nicht mit Microsoft verbunden und wird nicht von Microsoft unterstützt.