Plädoyer gegen eine dedizierte QA-Org in der Salesforce-Delivery

Kurz gesagt: Eine dedizierte QA-Org, also die eine gemeinsame Sandbox, die jede Änderung vor dem UAT durchlaufen muss, bremst Salesforce-Teams meist aus, ohne mehr Fehler zu finden. Sie erzeugt Warteschlangen, bündelt unabhängige Änderungen und driftet von der Produktion weg. Geben Sie jedem Work Item eine eigene kurzlebige Org, lassen Sie die Person, die eine Änderung baut, auch deren automatisierte Tests verantworten, und setzen Sie Tester für exploratives Testen und Abnahmen ein.

Was ist eine dedizierte QA-Org in der Salesforce-Delivery?

In den meisten Salesforce-Pipelines ist sie eine langlebige Sandbox zwischen Entwicklung und UAT, meist eine Developer Pro oder Partial Copy, in der jede Änderung landet, damit ein QA-Team sie testen kann. Der klassische Weg führt von der Dev-Sandbox über QA und UAT in die Produktion. Die QA-Org ist zugleich eine Stufe und oft ein Team, an dem jedes Ticket vorbei muss.

Warum bauen Salesforce-Teams eine?

Aus nachvollziehbaren Gründen. Tester wollen einen stabilen Arbeitsplatz. Änderungen verschiedener Personen müssen vor dem Release zusammenkommen. Integrationstests brauchen einen gemeinsamen Endpunkt. Und die Trennung von Ersteller und Prüfer ist ein gesunder Instinkt. Keines dieser Ziele ist falsch. Schief geht es, wenn eine einzige gemeinsame Org sie alle bedienen soll.

Was kostet Sie eine gemeinsame QA-Org wirklich?

• Serialisierte Arbeit. Wenn sich zehn Tickets eine Org teilen, blockiert eine fehlerhafte Änderung die anderen neun, und niemand erkennt, wessen Änderung den Fehler verursacht hat.
• Gebündelte Releases. Ausgeliefert wird „alles, was in QA ist“, keine Liste freigegebener Tickets. Eine Änderung zurückzunehmen heißt, den Rest zu entwirren, und genau so schleichen sich die versteckten Risiken im Salesforce-Deployment-Prozess ein.
• Drift. Hotfixes gehen direkt in die Produktion, aufgegebene Experimente bleiben liegen, und die Org entspricht nichts Realem mehr. Eine QA-Org zeigt meist als Erste, warum Sandboxes nicht mehr zur Produktion passen, weil alle darin arbeiten.
• Langsame Resets. Eine Partial-Copy-Sandbox lässt sich alle fünf Tage aktualisieren, eine Full-Sandbox alle 29 Tage, wie der Sandbox-Leitfaden von Salesforce Ben erläutert. Ist eine langlebige QA-Org erst einmal verunreinigt, leben Sie damit bis zum nächsten Refresh-Fenster.
• Eine späte Prüfung. Wer am Sprintende testet, findet Fehler dann, wenn sie am teuersten sind. Laut Gearsets State of Salesforce DevOps 2026 finden 18 % der Teams Probleme hauptsächlich in der Produktion. Eine weitere gemeinsame Stufe am Ende der Kette ändert an dieser Zahl nichts.

Wer verantwortet das Testen, wenn es keine QA-Org gibt?

Die Person, die die Änderung baut. Die DORA-Empfehlungen zur Testautomatisierung verknüpfen bessere Delivery-Leistung damit, dass Entwickler hauptsächlich für das Erstellen und Pflegen automatisierter Testsuites verantwortlich sind, und warnen: Gehören die Tests einer anderen Gruppe, bleibt die Pipeline kaputt, bis dieses Team sie repariert. Bei Salesforce zählt auch der Admin, der den Flow gebaut hat, zu den „Entwicklern“.

Tester werden dadurch nicht abgeschafft. DORA beschreibt Tester als „eine Rolle, nicht unbedingt eine Vollzeitstelle“ und betont ihre wesentliche Rolle bei explorativen Tests und Usability-Tests, gemeinsam mit den Entwicklern statt nach ihnen. Das Plädoyer richtet sich gegen die Warteschlange, nicht gegen die Menschen.

Was ersetzt eine gemeinsame QA-Org?

Eine Org pro Work Item. Jedes Ticket bekommt eine eigene Umgebung, seine Prüfungen laufen dort, und es geht in seinem eigenen Tempo weiter.

• Scratch-Orgs für isolierte Validierung. Laut Salesforce DX Developer Guide lässt sich die Lebensdauer einer Scratch-Org auf 1 bis 30 Tage festlegen, Standard sind 7 Tage. Sie werden aus dem Quellcode aufgebaut und nach dem Merge verworfen.
• Automatisierte Prüfungen bei jeder Änderung. Apex-Tests, statische Analyse und Code-Review laufen vor dem Merge, nicht erst, wenn eine gemeinsame Umgebung vollgelaufen ist.
• Ein schlankeres UAT. Fachanwender geben weiterhin frei, aber anhand einer bekannten Ticketliste statt dessen, was zufällig in QA liegt.
• Eine Full-Sandbox, wo echte Daten zählen. Finale Regressions-, Performance- und datenintensive Integrationstests brauchen weiterhin produktionsnahe Datenmengen, kurz am Ende eingesetzt.

Gemeinsame QA-Org vs. Org pro Work Item

• Warten: eine Warteschlange für einen Platz vs. standardmäßig parallel.
• Isolation: vermischte Änderungen vs. eine Änderung pro Org.
• Reset: an Refresh-Intervalle gebunden vs. aus dem Quellcode neu aufgebaut.
• Qualität entschieden: am Ende vs. bei jeder Änderung.

Der übliche Einwand sind die Kosten, und er ist berechtigt, wenn Ihr Tool pro Umgebung abrechnet. Eine Org pro Ticket wirkt in diesem Modell teuer, und genau das ist das Margenproblem der Pro-Org-Preise im Salesforce DevOps, das in Ihrer Teststrategie auftaucht.

Wann ist eine dedizierte QA-Org trotzdem richtig?

Es gibt echte Ausnahmen. Regulierte Teams brauchen unter Umständen einen dokumentierten Testzyklus in einer benannten Umgebung. Manche externen Systeme können nur auf einen einzigen Sandbox-Endpunkt zeigen. Große Regressionssuites können produktionsnahe Daten erfordern. Behalten Sie in diesen Fällen die Umgebung, aber machen Sie sie zur letzten Prüfung vor dem Release, nicht zur Warteschlange für jede Änderung.

Wie lösen Sie sich von einer gemeinsamen QA-Org?

1. Machen Sie das Ticket zur Release-Einheit, damit jede Änderung einzeln verfolgt und befördert wird.
2. Übertragen Sie automatisierte Tests an die Person, die die jeweilige Änderung erstellt, und führen Sie sie in der Org dieser Änderung aus.
3. Führen Sie vor dem Merge ein Validierungs-Deployment gegen das Ziel aus.
4. Reduzieren Sie die gemeinsame Umgebung auf Integrations- und explorative Arbeit, die wirklich eine braucht.
5. Messen Sie, wie viele Probleme vor und nach der Umstellung die Produktion erreichen.

FAQ

Heißt keine QA-Org auch keine QA-Engineers?

Nein. Tester steigen früher ein, arbeiten im Pairing an automatisierten Tests und übernehmen die explorativen und Usability-Tests, die DORA weiterhin als wesentlich bezeichnet.

Reichen Scratch-Orgs für alle Tests?

Nein. Sie eignen sich für die isolierte Validierung einer Änderung. Produktionsnahe Datenmengen und manche Integrationen brauchen weiterhin eine Partial-Copy- oder Full-Sandbox.

Wer schreibt die Tests, wenn ein Admin die Änderung baut?

Der Admin verantwortet die Prüfungen für die eigene Änderung, eine Kollegin oder ein Kollege prüft gegen. Verantwortung zählt mehr als die Jobbezeichnung.

Was sollte ein kleines Team zuerst ändern?

Hören Sie auf, unabhängige Tickets in eine gemeinsame Org zu deployen. Geben Sie jedem Ticket eine eigene Umgebung und behalten Sie eine einzige Sandbox für das UAT.

Serpent ist für dieses Modell gebaut: ticketbasierte Releases, KI-Code-Review in jedem Plan und vorgewärmtes Scratch-Org-Pooling in Scale, damit eine Umgebung pro Ticket in Sekunden bereitsteht. Der Preis ist pauschal pro Unternehmen ohne Gebühren pro Org, zusätzliche Umgebungen verursachen also keine Lizenzkosten. Vergleichen Sie die Pläne und starten Sie kostenlos mit Essentials.