Regressionstests nach einem CRM-Release

Warum ein CRM Regressionstests braucht

Nach dem Go-live ändert sich Ihr CRM weiter, auch wenn Ihr eigenes Team nichts ändert. Salesforce und Microsoft aktualisieren die Plattform für jeden Kunden. Die meisten Änderungen sind Verbesserungen. Manche ändern eine Seite, eine Standardeinstellung oder die Funktionsweise eines Features, und hin und wieder macht eine etwas kaputt, auf das Ihr Fachbereich angewiesen ist.

Ein Regressionstest beantwortet eine Frage: Funktioniert noch, was der Fachbereich beim Go-live abgenommen hat? Er ist kein neuer UAT. Er ist eine kurze, gezielte Prüfung der wichtigsten Prozesse, bevor die Änderung Ihre Benutzer erreicht, durch Personen, die die Arbeit kennen.

Ihre eigenen Releases brauchen dieselbe Prüfung. Eine neue Integration, ein neues Feld im Angebot, eine Änderung am Routing von Fällen: Jede davon kann etwas berühren, das vorher funktioniert hat.

Salesforce: drei Releases pro Jahr

Salesforce hat drei Haupt-Releases pro Jahr: Spring, Summer und Winter. Das Winter-Release kommt im Herbst und trägt die Jahreszahl des Folgejahres. Jede Org wird aktualisiert, zu Terminen, die Salesforce im Voraus veröffentlicht.

• 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 sagt Salesforce, welche Instanzen in der Preview sind und was Sie tun müssen, damit eine Sandbox dort bleibt. Ein Refresh kann eine Sandbox in die Preview hinein- oder aus ihr herausbringen, prüfen Sie das also rechtzeitig.
• Die Release Notes. Lesen Sie sie für die Clouds und Features, die Sie nutzen. Achten Sie darauf, was automatisch für Sie eingeschaltet wird und was das Aussehen der Seiten ändert, mit denen Ihre Benutzer arbeiten.
• Release Updates. Manche Änderungen werden im Setup mit einem Datum angekündigt, ab dem sie erzwungen werden. Testen Sie sie vor diesem Datum in der Sandbox, damit sie Sie in der Produktion nicht überraschen.

Für Salesforce ist der Rhythmus also vorgegeben: eine Regressionsrunde im Preview-Zeitfenster jedes Releases, dreimal pro Jahr.

In UAT StudioWählen Sie Salesforce als CRM des Projekts. Ab etwa zwei Monaten vor einem Release zeigt die Projektseite Coming CRM releases, mit dem Datum der Sandbox-Preview, dem Datum der Produktion und einem Link zu den Release Notes. Salesforce kann diese Termine noch verschieben, prüfen Sie also die Release Notes.

Dynamics 365: Updates das ganze Jahr

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.

Damit gibt es keinen großen Moment im Jahr mehr, um den herum Sie Ihre Tests planen können. Änderungen kommen in kleineren Schritten und häufiger. Auf ein großes Release zu warten funktioniert nicht mehr, und nach jeder einzelnen Änderung zu testen ist zu viel.

Wählen Sie einen festen Rhythmus

Die Antwort ist eine Regressionsrunde in einem festen Rhythmus, unabhängig davon, was Microsoft dazwischen veröffentlicht:

• Jeden Monat, wenn das CRM für den Fachbereich zentral ist, Sie viele Apps und Features nutzen oder häufig neue Features einschalten.
• Jedes Quartal für ein stabiles Setup mit wenigen eigenen Änderungen.
• Eine zusätzliche Runde, bevor eine eigene Änderung live geht oder wenn eine Änderung von Microsoft eindeutig einen Ihrer zentralen Prozesse berührt.

Tragen Sie die Termine für das ganze Jahr in den Kalender der Tester ein. Ein fester Rhythmus lässt sich leichter einhalten als eine Runde, die jedes Mal neu geplant wird, wenn etwas ansteht.

Vor jeder Runde

• Lesen Sie die Microsoft-Roadmap und die Nachrichten für Ihre Admins im Microsoft 365 admin center und notieren Sie, welche Änderungen Ihre Prozesse berühren.
• Probieren Sie Features in der Preview zuerst in einer Sandbox-Umgebung aus, bevor sie Ihre Benutzer erreichen.
• Stellen Sie sicher, dass die Sandbox, in der Sie testen, dieselbe Version und dieselben Lösungen hat wie die Produktion.

In UAT StudioWählen Sie Dynamics 365 als CRM des Projekts und starten Sie jede Runde mit Start a regression round, aus dem Projekt Ihres Go-lives oder Ihrer letzten Runde.

In UAT StudioWählen Sie unter Setup bei Check the Dynamics 365 updates: Every quarter oder Every month. Die Projektseite zeigt dann den aktuellen Zeitraum mit einem Link zur Roadmap, und Admins erhalten eine E-Mail pro Zeitraum, zwei Wochen bevor er beginnt.

Auswählen, was erneut getestet wird

Eine Regressionsrunde ist nicht der Ort, um alles noch einmal zu testen. Wählen Sie in dieser Reihenfolge:

1. Die Must-Testfälle. Was jeden Tag funktionieren muss: ein Angebot erstellen, einen Lead konvertieren, einen Fall weiterleiten, die Freigaben. Testen Sie sie in jeder Runde.
2. Was die Änderung berührt. Lesen Sie die Release Notes oder die Roadmap mit der Liste Ihrer Prozesse daneben. Eine Änderung an Angeboten bedeutet die Testfälle zu Angeboten, auch die Should- und Could-Testfälle.
3. Integrationen und Automatisierung. Die Verbindungen mit dem ERP, der Website oder der E-Mail und die Flows, die im Hintergrund laufen. Sie gehen unbemerkt kaputt, testen Sie sie also gezielt.
4. Die Should-Testfälle, wenn Zeit bleibt.

Sehen Sie sich dann an, was Ihr eigenes Team seit der letzten Runde geändert hat. Alles, was Sie selbst gebaut haben und niemand zusammen mit der Plattformänderung getestet hat, gehört ebenfalls in die Runde.

Führen Sie eine kurze Liste dessen, was kritisch ist

Schreiben Sie einmal die zehn bis zwanzig Prozesse auf, auf die der Fachbereich keinen Tag verzichten kann. Sie sind der Kern jeder Regressionsrunde. Überprüfen Sie die Liste jedes halbe Jahr mit den Prozessverantwortlichen und nach jeder großen eigenen Änderung.

In UAT StudioMit dem Add-on Release readiness zeigt Review the release, welche Ihrer Testfälle ein Salesforce-Release oder Dynamics 365-Update betrifft, mit Begründung, schlägt Testfälle für das vor, was noch nicht abgedeckt ist, und listet die erforderlichen Updates mit ihren Terminen auf. Die Regressionsrunde erhält dann genau die Must-Testfälle, die betroffenen, die Sie behalten, und die neuen, die Sie freigeben. Ein Fail in der Runde nennt die Änderung, mit der er kam. €99 pro Monat: Fügen Sie es unter Plan & billing hinzu.

Testfälle wiederverwenden

Der beste Regressionstest, den Sie haben, sind die Testfälle aus Ihrem Go-live-UAT. Sie beschreiben genau, was der Fachbereich abgenommen hat, mit den Schritten, den Testdaten und den erwarteten Ergebnissen. Schreiben Sie nicht für jede Runde neue.

• Behalten Sie die Testfälle nach dem Go-live an einem Ort, mit ihrer Priorität.
• Aktualisieren Sie sie, wenn sich Ihr eigener Prozess ändert, damit die nächste Runde das CRM so testet, wie es jetzt ist, nicht wie es beim Go-live war.
• Prüfen Sie die Testdaten vor jeder Runde. Ein Sandbox-Refresh oder eine Kopie der Produktion kann die Datensätze entfernen oder ändern, die die Testfälle verwenden.
• Ergänzen Sie einen Testfall für jedes schwerwiegende Issue, das in der Produktion gefunden wird, damit es beim nächsten Mal auffällt.

Testfälle, denen Tester aus dem Fachbereich folgen können, lohnen hier die Mühe: Sie werden immer wieder verwendet. Siehe Testfälle schreiben, die Tester aus dem Fachbereich verstehen.

In UAT StudioStart a regression round kopiert die Testfälle des Projekts, von dem Sie ausgehen, mit ihren Schritten, Testdaten und erwarteten Ergebnissen. Wählen Sie, welche mitkommen: Must and Should, Only Must oder All test cases in scope; ein Testfall ohne Priorität zählt als Should. Das neue Projekt erhält die Gruppen und Einstellungen, und Sie laden die Tester unter Setup ein. Nichts wird erfunden oder geändert.

Wer testet und wie lange

Wer

Eine Regressionsrunde braucht weniger Personen als ein UAT, aber sie sollten trotzdem aus dem Fachbereich kommen. Bitten Sie ein oder zwei Key User pro Prozess: Personen, die die Arbeit jeden Tag machen und sofort merken, wenn etwas nicht stimmt. Der CRM-Admin bereitet die Runde vor und testet, was im Hintergrund läuft, sollte aber nicht der einzige Tester sein.

Lassen Sie Runde für Runde dieselben Personen testen. Sie werden schneller und bemerken kleine Änderungen, die ein neuer Tester übersehen würde.

Wie lange

• Vorbereitung: ein bis zwei Tage, um die Änderungen zu lesen, die Testfälle auszuwählen und die Testdaten zu prüfen.
• Testen: ein paar Stunden pro Tester, verteilt auf ein oder zwei Tage bei einer monatlichen Runde, bis zu einer Woche bei einem Salesforce-Release mit vielen Änderungen.
• Fixes und Retests: Planen Sie ein paar Tage ein, bevor die Änderung die Produktion erreicht, für die Issues, die Sie finden.

Bei Salesforce muss das ins Preview-Zeitfenster passen. Beginnen Sie früh im Zeitfenster, nicht in der letzten Woche.

Erfassen, was Sie finden

Erfassen Sie Issues wie im UAT: den Schritt, was Sie erwartet haben, was stattdessen passiert ist, einen Screenshot und den Link zum Datensatz. Gehen Sie sie jeden Tag mit dem CRM-Team in der Triage durch. Bei einem Issue, das die Plattform verursacht, sehen Sie zuerst in den Release Notes oder der Roadmap nach: Oft ist es eine bekannte Änderung mit einer Einstellung, die sich anpassen lässt.

In UAT StudioJede Runde behält ihr Release, ihren Build und ihre Umgebung, sodass der go/no-go-Bericht sagt, was getestet wurde. Nach Fixes startet Start round 2 auf dem Dashboard mit Failed and blocked only einen Retest nur dessen, was schiefgegangen ist; die Ergebnisse der früheren Runde bleiben erhalten.

Abnahme vor der Produktion

Eine Regressionsrunde endet wie ein UAT mit einer Entscheidung, nur kürzer. Vereinbaren Sie die Ausgangskriterien einmal und verwenden Sie sie in jeder Runde:

• Jeder Must-Testfall ist bestanden.
• Kein Critical-Issue ist offen.
• Jedes offene High-Issue hat einen Workaround, den der Fachbereich akzeptiert, oder einen Fix, bevor die Änderung die Produktion erreicht.

Der Verantwortliche jedes Prozesses nimmt seinen Teil ab: abgenommen, abgenommen mit Auflagen oder abgelehnt. Bei einem Salesforce-Release können Sie das Upgrade nicht aufhalten, eine Ablehnung bedeutet also einen Fix oder einen Workaround vor dem Produktionstermin und eine Nachricht an die Benutzer. Bei einer eigenen Änderung bedeutet eine Ablehnung, dass sie wartet.

Bewahren Sie das Ergebnis jeder Runde auf. Nach einem Jahr haben Sie einen klaren Nachweis, was nach jeder Änderung getestet wurde und wer es abgenommen hat. Wie Sie die Entscheidung vorbereiten, lesen Sie in Die go/no-go-Entscheidung.

In UAT StudioEine Regressionsrunde ist ein eigenes Projekt, mit dem Release als Release, sodass sein go/no-go-Bericht sagt, um welches CRM-Release es geht. Die Prozessverantwortlichen nehmen pro Gruppe ab, und die Abnahme gehört zu dieser Runde.

Kostenlos nutzbar

Die UAT-Checkliste für einen CRM-Go-live funktioniert auch für eine Regressionsrunde, als kostenlose Excel-Datei. Für jede Plattform siehe Salesforce UAT und Dynamics 365 UAT.

Salesforce ist eine Marke von Salesforce, Inc. Microsoft und Dynamics 365 sind Marken der Microsoft-Unternehmensgruppe. UAT Studio ist nicht mit Salesforce oder Microsoft verbunden und wird nicht von ihnen unterstützt.