29 sep 2026 Salesforce testen voor een release: wat check je voordat Winter ’27 je org bereikt?
In het kort: Salesforce testen voor een release betekent: je eigen processen, code en koppelingen controleren op de nieuwe versie, voordat die in productie komt. Winter ’27 staat sinds eind augustus op de preview-sandboxes, en productie-orgs volgen ongeveer zes weken later. Draai je regressietests in een preview-sandbox en los op wat breekt voor je upgradedatum.
Drie keer per jaar zet Salesforce elke org over op een nieuwe release. Je kiest de datum niet zelf, en overslaan kan niet. Winter ’27 is de volgende. Salesforce test zijn eigen release. Je eigen velden, Flows, Apex-code en koppelingen test je zelf, en daar maakt Salesforce testen het verschil.
Wanneer komt Winter ’27 in je org?
Winter ’27 komt in twee stappen. Eerst de sandboxes. Volgens de sandbox preview-instructies van Salesforce gingen de preview-instances op 28 en 29 augustus 2026 over op Winter ’27. Sandboxes die op Summer ’26 bleven, gaan over op 9 of 10 oktober 2026. Daarna productie. Salesforce zegt dat productie-instances ongeveer zes weken na de start van de sandbox-preview worden geüpgraded. De precieze datum hangt af van je instance. Die zoek je op bij Salesforce Trust, de officiële statussite. Salesforce plant upgrades buiten piekuren en in het weekend, en raadt aan om in dat venster geen beheerwerk te plannen. Elke release volgt hetzelfde ritme: Spring in februari, Summer in juni en Winter in oktober. Je kunt er dus op plannen.
| Stap | Winter ’27 | Waar vind je het? |
|---|---|---|
| Release notes | Nu beschikbaar | Salesforce Help |
| Preview-sandboxes geüpgraded | 28–29 augustus 2026 | Sandbox preview-instructies |
| Overige sandboxes geüpgraded | 9–10 oktober 2026 | Sandbox preview-instructies |
| Productie geüpgraded | Ongeveer zes weken na de start van de preview; datum per instance | Salesforce Trust |
Wat test je voor een Salesforce-release?
Test de delen van je org die Salesforce niet zelf heeft gebouwd. Daar komt een platformwijziging samen met je eigen aanpassingen. Daar kan een release ook iets breken dat niemand dagenlang merkt. Begin bij wat het meeste pijn doet als het stopt. Werk daarna deze lijst af.
- Belangrijkste processen: een lead aanmaken en omzetten, een opportunity afsluiten, een case afhandelen. Test ze van begin tot eind met realistische data.
- Eigen code en automatisering: Apex, Flows, validatieregels en eigen pagina-onderdelen, vooral waar ze standaardobjecten raken.
- Koppelingen en geplande jobs: data van en naar je ERP, marketingtools of website. Niemand kijkt daar elke dag naar, dus ze breken ongemerkt.
- Rechten: profielen, permission sets en deelregels. Een release kan veranderen wat een gebruikersrol mag zien.
- Rapporten en dashboards: de rapporten waar je managers besluiten op nemen.
- Release updates: wijzigingen die Salesforce op een vaste datum voor iedereen aanzet. Je vindt ze in Setup onder Release Updates. Zet ze eerst in een sandbox aan en test daar. In de release notes van Winter ’27 staat wat er verandert.
Hoe gebruik je de sandbox-preview?
Met de sandbox-preview krijg je een kopie van je org op de nieuwe release, weken voordat productie hem krijgt. Dat is dus de beste plek om te testen. Voor Winter ’27 moest een sandbox uiterlijk op 27 augustus 2026 zijn aangemaakt of ververst om mee te doen. Salesforce publiceert die uiterste datum voor elke release. Zo gebruik je de preview in vijf stappen.
- Houd bij elke release minstens één sandbox op de preview. Zet de uiterste datum in je agenda.
- Draai dezelfde regressietests in de preview-sandbox en in een sandbox op de huidige release.
- Vergelijk de resultaten. Faalt een test alleen op de preview, dan zit het in de release. Faalt hij in allebei, dan zit het in je eigen org.
- Los op of pas aan wat breekt, en test opnieuw voor je productiedatum.
- Bewaar de resultaten als begin van je checklist voor de volgende release.
Heb je de preview deze keer gemist? Test dan direct na de upgrade, begin bij de processen die het meeste pijn doen, en plan de preview voor Spring ’27.
Waarom automatiseer je Salesforce-regressietests?
Omdat het werk drie keer per jaar terugkomt, bovenop elke wijziging van je eigen team. Handmatig Salesforce testen betekent inloggen als verschillende gebruikers, door de belangrijkste processen klikken en de data controleren. Met veel rollen en processen kost dat al snel dagen. Geautomatiseerde tests doen dezelfde controles elke nacht en na elke release, zodat je binnen een paar uur weet of er iets stuk is. Salesforce bouwt zijn pagina’s dynamisch op en past ze aan tussen releases. Daardoor zijn algemene testtools op Salesforce kwetsbaar. Tools die voor het platform zijn gemaakt, zoals Provar, lezen de metadata van Salesforce zelf en kunnen beter tegen die veranderingen. Wij zijn Provar-partner. Voor elke tool geldt hetzelfde: kies er een die Salesforce begrijpt. Houd de testset klein genoeg om bij te houden.
Automatisering helpt ook bij het werk dat mensen vaak overslaan. Na een drukke releaseweek wil niemand voor tien gebruikersrollen de rechten doorklikken, dus die controles vallen als eerste af. Geautomatiseerde tests doen ze elke keer. Een risico dat we in veel teams zien, geldt ook voor Salesforce: de kwaliteit hangt aan één of twee mensen die weten hoe alles echt werkt. Dan kun je een release alleen goed testen als zij er zijn. Een geautomatiseerde testset haalt die afhankelijkheid weg.
Wat betekent dit voor je team?
Zoek vandaag je productiedatum op bij Salesforce Trust. Schrijf daarna de vijf processen op die op de maandag na de upgrade moeten werken, en test ze in een preview-sandbox. Heb je al geautomatiseerde tests, draai ze daar. Heb je ze nog niet, dan is deze release een goed moment om met die vijf te beginnen.
Nekst test Salesforce-releases samen met je beheerders en ontwikkelaars, en je team beslist wat live gaat. Voor de wereldwijde Salesforce-implementatie van IMCD zetten we de testscenario’s op, draaiden we veel testcycli en hielpen we bij de datamigratie, met een ambitieuze planning. Marco Vleeschdraager van IMCD zei daarover: “Having Nekst IT on board gave relief and reassurance to the project team”. Met Salesforce Quality Solutions krijg je testers die het platform kennen. Met Test Automation as a Service draaien je regressietests elke nacht, release na release, en houden wij ze draaiend.
Maak je Salesforce-org klaar voor elke seizoensrelease, met tests die draaien terwijl je team aan het volgende werkt.
Veelgestelde vragen
Hoe vaak brengt Salesforce een release uit?
Salesforce heeft drie grote releases per jaar: Spring in februari, Summer in juni en Winter in oktober, volgens de FAQ over het releaseschema. Elke org wordt automatisch geüpgraded, dus elke release vraagt om een testronde.
Wat is Salesforce testen?
Met Salesforce testen controleer je of je org nog doet wat je organisatie nodig heeft. Het gaat om je processen, eigen code, automatisering, koppelingen en rechten. Je test na je eigen wijzigingen en voor elk van de drie seizoensreleases.
Is Salesforce testen moeilijk?
Beginnen is makkelijk: klik in een sandbox door je belangrijkste processen. Het wordt lastiger naarmate je org groeit. Dynamische pagina’s, veel gebruikersrollen en koppelingen maken handmatig testen traag, en algemene testtools kunnen breken als Salesforce zijn pagina’s aanpast.
Welke tools gebruik je voor Salesforce testen?
Dat hangt af van je team en je org. Tools die speciaal voor Salesforce zijn gemaakt, zoals Provar, kunnen goed om met de dynamische pagina’s. Algemene tools zoals Selenium of Playwright werken ook, maar vragen op Salesforce meer onderhoud. Voor Apex-code heeft Salesforce eigen unittests, die je ontwikkelaars al nodig hebben om code uit te rollen.