In het kort: Salesforce-testautomatisering breekt het vaakst na kleine wijzigingen in je eigen org, niet alleen na de drie grote releases per jaar. Een hernoemd veld, een nieuwe validatieregel of een schermupdate laat flows en testscripts verderop omvallen. Je houdt regressie onder controle door bedrijfslogica onder het scherm te testen, koppelingen bewust aan te pakken en de regressieset na elke wijziging te draaien.

De meeste teams bereiden zich goed voor op de Spring-, Summer- en Winter-release. Ze lezen de release notes, testen in een sandbox en plannen een regressieronde. En dan, in een rustige week ertussen, hernoemt een beheerder een veld of voegt een validatieregel toe. Opeens kleurt de helft van de geautomatiseerde tests rood. Niemand heeft de tests aangepast. De org is onder ze veranderd.

Waarom breken Salesforce-tests na een kleine wijziging?

Salesforce-tests breken na kleine wijzigingen omdat alles in een org met elkaar verbonden is. Een veld wordt gebruikt in een flow, en de flow werkt een record bij. Dat record voedt een rapport en een koppeling. Een testscript volgt dat hele pad via het scherm. Verander één schakel en het effect duikt ergens anders op. In de projecten waar onze Salesforce-testers geautomatiseerde testsets onderhouden, komen steeds vier oorzaken terug:

• Kleine wijzigingen, grote gevolgen. Een veld hernoemen of een validatieregel aanpassen laat flows en scripts verderop falen, vaak ver van de wijziging zelf.
• Koppelingen die laat antwoorden. Koppelingen met marketingtools, productdatasystemen of samenwerkingstools geven timingproblemen. API-limieten en vertraging bij het synchroniseren laten tests af en toe falen, en die fouten zijn lastig na te bootsen.
• Schermupdates. Als Salesforce de opbouw van een pagina verandert, bijvoorbeeld met Lightning-updates, moeten de locators die een script vertellen waar het moet klikken worden bijgewerkt.
• Uitslagen die niemand leest. Als testrapporten niet laten zien wat de business wil weten, worden fouten laat opgemerkt.

Deze problemen zie je ook bij goede teams. Ze ontstaan als je een systeem dat steeds verandert vooral via het scherm test.

Na welke Salesforce-wijzigingen draai je een regressietest?

Na elke wijziging die data, logica of toegang raakt, draai je een regressietest, niet alleen bij de releases. Een simpele vuistregel helpt: kan een beheerder het aanpassen in Setup, dan kan het een test breken. Plan in de praktijk een run na wijzigingen in de onderdelen hieronder.

• velden, picklistwaarden en paginalay-outs.
• validatieregels en verplichte velden.
• flows, goedkeuringsprocessen en Apex-code.
• profielen, permission sets en deelregels.
• koppelingen, connected apps en hun instellingen.
• de drie releases per jaar, eerst getest in een preview-sandbox.

Voor het releaseseizoen zelf is er een aparte checklist voor Salesforce testen voor een release. In onze ervaring breekt er alleen veel in de maanden tussen de releases, na je eigen wijzigingen.

Hoe maak je Salesforce-testautomatisering minder kwetsbaar?

Je maakt Salesforce-testautomatisering minder kwetsbaar door elke regel te testen op het laagste niveau waar dat kan. Bewaar de schermtests voor wat gebruikers echt doen. Vier maatregelen maken het grootste verschil:

1. Test logica onder het scherm. Salesforce heeft ingebouwde flowtests voor record-triggered en autolaunched flows, en Apex heeft eigen unittests. Bedrijfsregels die je daar test, draaien snel en trekken zich niets aan van waar een knop staat. Voor koppelingen werkt hetzelfde idee via de API.
2. Gebruik stabiele locators. Scripts die velden vinden via de Salesforce-metadata, in plaats van via hun plek op de pagina, overleven de meeste schermwijzigingen. Tools die voor Salesforce zijn gebouwd kunnen dat; algemene browserscripts vaak niet.
3. Pak koppelingen bewust aan. Gaat een test niet over de koppeling, vervang die dan door een stand-in. Gaat hij er wel over, wacht dan op een specifiek resultaat in plaats van een vast aantal seconden. Zet die tests in een aparte groep, zodat één trage koppeling niet de hele run rood maakt.
4. Beheer je testdata. Tests die hun eigen records aanmaken en na afloop opruimen, falen niet omdat iemand een record in de sandbox heeft aangepast.

Waar past Provar?

Provar is een tool voor testautomatisering die speciaal voor Salesforce is gebouwd, en Nekst werkt er als partner mee. De grootste kracht is dat Provar de Salesforce-metadata begrijpt, waardoor tests minder gevoelig zijn voor schermwijzigingen dan algemene browserscripts. Onderhoud verdwijnt daarmee niet. Onze testers werken tests nog steeds bij na grotere schermwijzigingen, en koppelingen vragen nog steeds de aandacht die hierboven staat. De rapportage in Provar geeft de business ook niet altijd het overzicht dat ze wil, dus voegen we vaak een korte samenvatting per release toe. In de documentatie van Provar zie je hoe het werkt. Andere tools kunnen ook. Belangrijker dan de tool is wie de testset op orde houdt.

Wat betekent dit voor je team?

Een Salesforce-regressieset blijft niet vanzelf betrouwbaar. Iemand moet weten welke wijzigingen van beheerders eraan komen en na elke wijziging de tests draaien. Iemand lost op wat breekt en vertelt de business wat de uitslagen betekenen. In veel teams valt dat tussen beheerders, ontwikkelaars en testers in, en gebeurt het dus niet. Een korte afspraak helpt al: beheerders melden wijzigingen in een gedeeld kanaal, en elke wijziging start de regressierun.

We deden dit soort werk bij grote projecten, zoals de wereldwijde Salesforce-uitrol bij IMCD. Daar zetten we testscenario’s op, draaiden we veel testcycli en hielpen we bij de datamigratie. Met Test Automation as a Service houden we je Salesforce-regressieset draaiend, samen met je team, na elke wijziging en elke release. Zo kunnen je beheerders de org blijven verbeteren zonder iets te breken. Lees meer op onze pagina over Salesforce testen.

Veelgestelde vragen

Welke soorten testen zijn er in Salesforce?

De belangrijkste zijn unittests voor Apex-code en flowtests voor automatisering. Dan volgen tests van bedrijfsprocessen en van koppelingen met andere systemen. Daarbij komen regressietests na wijzigingen en releases, en acceptatietests met de mensen die elke dag in Salesforce werken.

Hoe vaak draai je Salesforce-regressietests?

Na elke wijziging die data, logica of toegang raakt, en voor elk van de drie releases per jaar. Klinkt dat als veel, dan is dat een teken dat de tests geautomatiseerd moeten worden en in een pipeline moeten draaien.

Kun je Salesforce-flows automatisch testen?

Ja. Salesforce heeft ingebouwde flowtests voor record-triggered en autolaunched flows, en die kunnen meedraaien in je regressie- en deploymentproces. Screen flows hebben nog steeds tests nodig die via het scherm gaan.

Is Provar de enige optie voor Salesforce-testautomatisering?

Nee. Provar is voor Salesforce gebouwd en gaat goed om met de metadata, maar andere tools kunnen ook. Kies op basis van de kennis in je team, je koppelingen en wie de tests gaat onderhouden.