Testautomatisierung für Dynamics 365: Warum brechen Anpassungen bei der Release Wave?
Microsoft aktualisiert Dynamics 365 zweimal im Jahr, im April und im Oktober, und das Update erreicht auch die Produktion. Standardfunktionen brechen selten; Ihre eigenen Anpassungen — JavaScript, Plug-ins, alte Formularsteuerelemente, veraltete APIs, PCF-Komponenten, Power-Automate-Flows und Integrationen — dagegen schon. Die Antwort ist eine risikobasierte, automatisierte Regressionssuite mit 30–50 Testfällen, die Wochen vor dem Produktiv-Update gegen die Early-Access-Version der Welle in einer Sandbox läuft.
Was ist eine Release Wave, und wann kommt sie?
Eine Release Wave ist die halbjährliche Update-Welle von Microsoft für Dynamics 365 und die Power Platform. Welle 1 startet im April, Welle 2 im Oktober und erreicht in den folgenden Monaten stufenweise jeden Mandanten. Den Inhalt veröffentlicht Microsoft vorab in den Release-Plänen, Abkündigungen in der Liste der veralteten Funktionen.
Etwa zwei Monate vor der allgemeinen Verfügbarkeit lässt sich die Welle per Early Access in einer Sandbox aktivieren. In diesen sechs bis acht Wochen kann ein Fehler noch in der Testumgebung gefunden und behoben werden. Wer sie auslässt, erfährt am Morgen des Produktiv-Updates, was gebrochen ist — von seinen Anwendern.
Warum brechen Anpassungen und nicht die Standardfunktionen?
Standardfunktionen testet Microsoft vor jeder Welle selbst. Ihre eigenen Entwicklungen kennt bei Microsoft niemand: das JavaScript, das auf das Laden eines Formularfelds wartet, das Plug-in, das sich auf eine bestimmte Nachrichtenreihenfolge verlässt, den Power-Automate-Flow, der den alten Wert eines Felds überwacht. Die Welle verändert deren Umgebung, und daran brechen sie — oft ohne Fehlermeldung.
| Komponente | Was gefährdet ist | Was wir testen |
|---|---|---|
| Eigenes JavaScript in Formularen | nicht unterstützter DOM-Zugriff, veraltete Xrm.Page-Aufrufe, zeitabhängiger Code; fällt bei Oberflächenänderungen still aus | ausgeblendete Felder, Standardwerte, Pflichtfelder, Schaltflächen im Formular |
| Plug-ins und benutzerdefinierte Workflow-Aktivitäten | geänderte Nachrichtenreihenfolge oder Plattformverhalten, veraltete SDK-Aufrufe, Timeouts | das Ergebnis der Geschäftslogik beim Speichern oder Statuswechsel |
| Alte Formularsteuerelemente und Oberflächenelemente | Microsoft kündigt sie ab; die Funktion verschwindet oder verhält sich anders | Darstellung und Verhalten der betroffenen Formulare |
| Veraltete (deprecated) APIs | eine angekündigte Abkündigung wird in einer späteren Welle wirksam | Integrationen, Skripte und Berichte, die den alten Endpunkt aufrufen |
| PCF-Komponenten | Versionswechsel des Frameworks oder seiner Bibliotheken | Laden, Datenverarbeitung und Speichern des eigenen Steuerelements |
| Power-Automate-Flows | Änderungen an Konnektoren oder Triggern, geänderte Feldwerte | Genehmigungen, Benachrichtigungen, Dokumenterzeugung von Ende zu Ende |
| Integrationen (ERP, Fakturierung, Webshop) | eine Änderung auf CRM-Seite verursacht einen Fehler im anderen System | Datenaustausch Feld für Feld, auch unterhalb der Oberfläche (API-Tests) |
| Standardfunktionen | brechen selten; Microsoft testet sie selbst | nur als Teil unserer eigenen Prozesse, nicht gesondert |
Der gemeinsame Nenner: Je mehr Anpassungen und Integrationen, desto höher das Risiko und desto teurer ist es, das System vor jeder Welle von Hand durchzuklicken. Deshalb ist die Release Wave das stärkste Argument für Testautomatisierung in Dynamics 365.
Wie sieht ein Regressionsprozess für die Release Wave aus?
- 1Risikobasierte Testsuite
Wir automatisieren nicht alles. Geschäftskritische und angepasste Prozesse werden priorisiert — Lead → Angebot → Auftrag, Anfrage → SLA → Abschluss, ERP-Übergabe —, daraus entstehen die ersten 30–50 Testfälle. Bei einem mittleren System decken sie rund 80 % des Risikos ab.
- 2Nächtliche Läufe in der CI
Die Suite läuft jede Nacht und vor jedem Deployment (Azure DevOps, GitHub Actions, Jenkins). Vor der Welle wissen wir also, dass auf der aktuellen Version alles grün ist — was danach rot wird, ist wegen des Updates rot.
- 3Early Access in der Sandbox
Wir aktivieren den Early Access der Welle in einer aus der Produktion aktualisierten Sandbox und führen dort die vollständige Regressionssuite aus.
- 4Analyse der Fehlschläge
Bei jedem roten Test entscheiden wir: echter Fehler im System oder nur eine Oberflächenänderung (neues Layout, umbenannte Schaltfläche)? Anhand von Screenshots, Protokollen und dem Plugin Trace Log.
- 5System oder Test korrigieren
Bei einem echten Fehler korrigieren wir die Anpassung (etwa durch Ablösung nicht unterstützten JavaScripts), bei einer Oberflächenänderung passen wir den Test an. Danach erneuter Lauf, bis alles grün ist.
- 6Freigabeentscheidung
Eine Testzusammenfassung: was lief, was fehlschlug, was noch offen ist. Auf dieser Grundlage geben wir das Update für die Produktion frei.
Welches Werkzeug: Tricentis Tosca, Katalon oder Playwright?
Ausführlicher Vergleich: Tricentis Tosca, Katalon oder Playwright? Mit jedem der drei prüfen wir Integrationen zusätzlich unterhalb der Oberfläche mit API-Tests (Postman, Newman in der CI).
Was testen wir manuell, was automatisiert?
Automatisierung schützt das Bestehende, sie testet nicht das Neue. Neue Funktionen der Welle und die geänderte Oberfläche prüfen wir von Hand, denn dort ist menschliches Urteil gefragt: Wird die neue Funktion gebraucht, verwirrt sie die Anwender, soll sie aktiviert werden?
Wo die Grenze verläuft und wann sich Automatisierung rechnet, zeigt ein Rechenbeispiel: manuell oder automatisiert testen — wann lohnt es sich?
Wie läuft das im Support-Vertrag?
Im monatlichen Dynamics-365-Support ist die Vorbereitung auf die Release Wave Teil der Leistung, kein eigenes Projekt:
Leistungsdetails und Werkzeuge: Softwaretests und Testautomatisierung.
Warum ist es wichtig, dass CRM-Berater und Testingenieure ein Team sind?
Bei einer Release Wave ist der fehlgeschlagene Test nur die halbe Frage. Die andere Hälfte: Warum ist er fehlgeschlagen, und was muss korrigiert werden — das JavaScript, das Plug-in, der Flow oder der Test? Sitzen Tester und Dynamics-Berater in zwei verschiedenen Firmen, pendelt diese Frage wochenlang zwischen Tickets. Bei uns baut dasselbe Team die Anpassung, schreibt den Test und analysiert den Fehler; die Dynamics-CRM-Prüfungen (MB2-704, MB2-707, MB5-705) und die Tricentis-Tosca-Zertifizierungen liegen im selben Team.
Häufige Fragen
Wann erscheint die Dynamics-365-Release-Wave?
Zweimal im Jahr: Welle 1 startet im April, Welle 2 im Oktober und erreicht in den folgenden Monaten stufenweise jeden Mandanten. Per Early Access lässt sie sich etwa zwei Monate früher in einer Sandbox ausprobieren.
Lässt sich eine Release Wave verschieben?
Nicht dauerhaft. Das Update ist verpflichtend und erreicht die Produktion zum geplanten Update-Termin des Mandanten. Deshalb müssen die Tests während des Early Access in der Sandbox laufen.
Wie viele Testfälle sollte man automatisieren?
Bei einem mittleren System decken 30–50 risikobasiert ausgewählte Testfälle rund 80 % des Risikos ab. Ziel ist nicht die Anzahl, sondern die Abdeckung der geschäftskritischen und angepassten Prozesse.
Wie schnell läuft eine Regressionssuite?
Die erste Runde deckt die kritischsten Prozesse mit automatisierten Tests ab, die bereits in der CI laufen; danach wächst die Suite laufend.
Brauchen wir eine eigene Testumgebung?
Ja, wir testen nie in der Produktion. Nötig ist eine aus der Produktion aktualisierte Sandbox, in der sich der Early Access der Welle aktivieren lässt.
Sprechen wir über Ihr Projekt.
Schreiben Sie uns, was Sie planen — wir melden uns innerhalb weniger Tage.
Kontakt aufnehmen