Pleidooi tegen een aparte QA-org in Salesforce-delivery

De korte versie: een aparte QA-org, die ene gedeelde sandbox waar elke wijziging doorheen moet vóór UAT, vertraagt Salesforce-teams vooral zonder meer defecten te vinden. Werk raakt in een wachtrij, losse wijzigingen worden gebundeld en de org drijft weg van productie. Geef elk work item een eigen kortlevende org, laat wie een wijziging bouwt ook eigenaar zijn van de geautomatiseerde tests ervan, en zet testers in voor verkennend werk en acceptatie.

Wat is een aparte QA-org in Salesforce-delivery?

In de meeste Salesforce-pipelines is het een langlevende sandbox tussen development en UAT, meestal een Developer Pro of Partial Copy, waar elke wijziging terechtkomt zodat een QA-team die kan testen. Het klassieke pad loopt van dev-sandbox naar QA, UAT en productie. De QA-org is zowel een fase als, vaak, een team waar elk ticket langs moet.

Waarom bouwen Salesforce-teams er een?

Om begrijpelijke redenen. Testers willen een stabiele werkplek. Wijzigingen van verschillende mensen moeten elkaar vóór de release ontmoeten. Integratietests hebben een gedeeld endpoint nodig. En de bouwer scheiden van de controleur is een gezond instinct. Geen van die doelen is fout. Het gaat mis wanneer je ze allemaal met één gedeelde org wilt bedienen.

Wat kost een gedeelde QA-org je echt?

• Werk na elkaar in plaats van naast elkaar. Als tien tickets één org delen, blokkeert één kapotte wijziging de andere negen, en niemand ziet wiens wijziging de fout veroorzaakte.
• Gebundelde releases. Wat live gaat is "alles wat in QA staat", geen lijst met goedgekeurde tickets. Eén wijziging terugdraaien betekent de rest ontwarren, en precies zo sluipen de verborgen risico's in een Salesforce-deploymentproces binnen.
• Drift. Hotfixes gaan direct naar productie, verlaten experimenten blijven achter en de org lijkt op niets echts meer. Een QA-org laat meestal als eerste zien waarom sandboxes niet meer overeenkomen met productie, omdat iedereen eraan zit.
• Trage resets. Een Partial Copy-sandbox kan elke vijf dagen worden ververst en een Full-sandbox elke 29 dagen, zoals de sandboxgids van Salesforce Ben uitlegt. Is een langlevende QA-org eenmaal vervuild, dan leef je ermee tot het volgende refreshvenster.
• Een late poort. Testen aan het eind van de sprint vindt defecten wanneer ze het duurst zijn. Gearsets State of Salesforce DevOps 2026 meldt dat 18% van de teams problemen vooral in productie vindt. Nog een gedeelde fase aan het eind van de lijn verandert dat getal niet.

Wie is eigenaar van testen als er geen QA-org is?

Degene die de wijziging bouwt. De richtlijn voor testautomatisering van DORA koppelt betere delivery-prestaties aan developers die primair verantwoordelijk zijn voor het maken en onderhouden van geautomatiseerde testsuites, en waarschuwt dat de pipeline kapot blijft tot een ander team de tests repareert wanneer dat team er eigenaar van is. Bij Salesforce valt ook de admin die de Flow bouwde onder "developer".

Dat schaft testers niet af. DORA noemt tester "een rol, niet per se een fulltime baan" en zegt dat testers een essentiële rol spelen bij verkennend testen en usability-testen, naast developers in plaats van na hen. Het pleidooi is tegen de wachtrij, niet tegen de mensen.

Wat vervangt een gedeelde QA-org?

Een org per work item. Elk ticket krijgt een eigen omgeving, de eigen checks draaien daar, en het gaat in een eigen tempo verder.

• Scratch orgs voor geïsoleerde validatie. Met de Salesforce DX Developer Guide stel je de levensduur van een scratch org in op 1 tot 30 dagen, met 7 als standaard. Ze worden vanuit source gebouwd en weggegooid zodra het werk is gemerged.
• Geautomatiseerde checks op elke wijziging. Apex-tests, statische analyse en code review draaien vóór de merge, niet nadat een gedeelde omgeving is volgelopen.
• Een kleinere UAT. Business-gebruikers keuren nog steeds goed, maar tegen een bekende lijst tickets in plaats van wat er toevallig in QA staat.
• Een Full-sandbox waar echte data telt. Laatste regressie-, performance- en data-intensieve integratietests verdienen nog steeds productie-achtige volumes, kort ingezet aan het eind.

Gedeelde QA-org vs org per work item

• Wachten: een wachtrij voor één plek vs standaard parallel.
• Isolatie: wijzigingen door elkaar vs één wijziging per org.
• Reset: gebonden aan refresh-intervallen vs opnieuw opgebouwd vanuit source.
• Kwaliteit bepaald: aan het eind vs bij elke wijziging.

Het gebruikelijke bezwaar is kosten, en dat is terecht als je tooling per omgeving factureert. Een org per ticket oogt in dat model duur, en dat is het margeprobleem van prijzen per org in Salesforce DevOps dat opduikt in je teststrategie.

Wanneer is een aparte QA-org nog wel de juiste keuze?

Er zijn eerlijke uitzonderingen. Gereguleerde teams hebben soms een gedocumenteerde testcyclus in een benoemde omgeving nodig. Sommige externe systemen kunnen maar naar één sandbox-endpoint wijzen. Grote regressiesuites kunnen productie-achtige data vereisen. Houd in die gevallen de omgeving, maar maak er de laatste check vóór de release van, geen wachtrij waar elke wijziging in staat.

Hoe stap je af van een gedeelde QA-org?

1. Maak het ticket de eenheid van release, zodat elke wijziging los wordt gevolgd en gepromoot.
2. Leg geautomatiseerde tests bij de auteur van elke wijziging en draai ze in de org van die wijziging.
3. Draai vóór de merge een validatiedeployment tegen het doel.
4. Beperk de gedeelde omgeving tot het integratie- en verkennende werk dat er echt een nodig heeft.
5. Meet hoeveel problemen productie bereiken, vóór en na de overstap.

FAQ

Betekent geen QA-org ook geen QA-engineers?

Nee. Testers schuiven naar voren, pairen op geautomatiseerde tests en doen het verkennende en usability-testen dat DORA nog steeds essentieel noemt.

Zijn scratch orgs genoeg voor al het testen?

Nee. Ze passen bij geïsoleerde validatie van één wijziging. Productie-achtige datavolumes en sommige integraties vragen nog steeds om een Partial Copy- of Full-sandbox.

Wie schrijft de tests als een admin de wijziging bouwt?

De admin is eigenaar van de checks voor de eigen wijziging, met een collega die meekijkt. Eigenaarschap telt meer dan functietitel.

Wat moet een klein team als eerste veranderen?

Stop met het deployen van losse tickets in één gedeelde org. Geef elk ticket een eigen omgeving en houd één sandbox voor UAT.

Serpent is gebouwd voor dit model: releases op basis van tickets, AI-codereview op elk abonnement en vooraf opgewarmde scratch org-pooling op Scale, zodat een omgeving per ticket binnen seconden klaarstaat. De prijs is vast per bedrijf zonder kosten per org, dus extra omgevingen voegen geen licentiekosten toe. Vergelijk de abonnementen en begin gratis met Essentials.