Salesforce UAT: een praktische gids

Wanneer je een UAT in Salesforce nodig hebt

Een acceptatietest beantwoordt één vraag: kan de business haar werk doen in deze versie van Salesforce? De mensen die het werk doen, testen het, in hun eigen woorden, voordat het in productie gaat. Op deze momenten heb je er een nodig.

• Een go-live. De eerste Sales Cloud of Service Cloud, of een overstap vanuit een ander CRM.
• Een nieuwe cloud of een grote wijziging. Service Cloud naast Sales Cloud, CPQ, een nieuwe koppeling met het ERP, of een nieuwe manier om cases te routeren.
• Elke Salesforce-release. Salesforce heeft drie releases per jaar: Spring, Summer en Winter. De Winter-release komt in het najaar en draagt het nummer van het volgende jaar. Elke release kan veranderen hoe je org werkt, ook als je zelf niets hebt veranderd.
• De sandbox preview. Sandboxes op een preview-instance krijgen de nieuwe release enkele weken vóór productie. Dat is je venster om te testen. Vóór elke release publiceert Salesforce welke instances in de preview zitten en wat je moet doen om een sandbox daar te houden. Controleer dat op tijd, want een refresh kan een sandbox in of uit de preview halen.

Een go-live vraagt om een volledige UAT. Een release vraagt om een kortere regressietest van de processen die het meest tellen. Meer daarover onder Na de go-live.

De sandbox

Test nooit in productie. Salesforce heeft vier typen sandbox. Twee daarvan zijn geschikt voor een UAT.

Plan de refresh

Een refresh vervangt alles in de sandbox door een nieuwe kopie van productie. Elk type sandbox heeft een minimale tijd tussen twee refreshes, en een Full sandbox de langste. Plan het dus:

• Refresh vóór de UAT, nooit tijdens. Controleer wanneer de sandbox weer gerefresht kan worden.
• Deploy de release na de refresh naar de sandbox. Werk dat alleen in de sandbox bestond, is weg.
• Voer de stappen na een refresh uit: laat koppelingen en named credentials naar testsystemen wijzen, niet naar productie, en zet geplande jobs uit die niet mogen draaien.
• Controleer de e-mailbezorging (Deliverability). Een nieuwe of gerefreshte sandbox verstuurt alleen systeemmail. Antwoorden op web-to-lead, goedkeuringen en case-e-mails hebben meer nodig, maar een Full sandbox bevat de echte e-mailadressen van je contactpersonen. Gebruik testadressen voordat je het openzet.

Testdata

Testers verliezen uren als de data niet klaar is. Bereid die voor vóór de eerste testdag:

• Accounts en contactpersonen voor elk type klant dat je test, met de juiste eigenaar, regio en recordtype.
• Producten en prijsboeken. Een product heeft een prijs in het standaardprijsboek nodig voordat het in een ander prijsboek kan staan. Controleer of de prijsboeken van elk salesteam actief zijn.
• Open records om aan te werken: opportunities in verschillende fasen, open cases, en cases die bijna een milestone bereiken als je entitlements test.
• Geen echte persoonsgegevens waar je dat kunt vermijden. Een Full sandbox kopieert alles, dus maskeer of anonimiseer wat testers niet hoeven te zien.

Gebruikers per profiel en permission set

Een UAT bewijst dat elke rol zijn werk kan doen, en alleen zijn werk. Maak een testgebruiker voor elke combinatie van profiel, rol en permission sets die je test, zoals een verkoper, een salesmanager en een servicemedewerker. Elke tester krijgt een eigen gebruiker, zodat twee mensen nooit tegelijk in dezelfde gebruiker werken.

Na een refresh zet Salesforce de naam van de sandbox achter elke gebruikersnaam en .invalid achter het e-mailadres van elke gebruiker. Zet het e-mailadres van elke testgebruiker op een adres dat de tester leest, anders komen wachtwoordresets en goedkeuringsmails nergens aan.

Met Log in as ziet een admin Salesforce door de ogen van een andere gebruiker. Zo bekijk je goed een probleem dat een tester meldt. Voor de test zelf gebruiken testers hun eigen testgebruiker: zo weet je dat het profiel en de permission sets kloppen.

Wat je testers vertelt over de sandbox

• Het adres van de sandbox. Daarin staat de naam van de sandbox, of ze loggen in via test.salesforce.com. De gewone inlogpagina van Salesforce opent productie.
• Hun gebruikersnaam, die eindigt op de naam van de sandbox, en hoe ze hun wachtwoord krijgen.
• Dat de data testdata is: niets wat ze doen bereikt een echte klant, en niets wat ze zien is actueel.
• Wie ze bellen als ze niet kunnen inloggen, voordat ze een ochtend kwijt zijn.

In UAT StudioElke tester krijgt een Test role en een Test account, bovenaan hun tests getoond als Log in as …. In de Notes for testers staan het adres van de sandbox, testmailboxen en wie ze kunnen bellen.

Testcases uit user stories en processen

Begin bij de processen van de business, niet bij de objecten in Salesforce. Twee processen dekken het grootste deel van een Salesforce-UAT:

• Lead to cash. Een lead komt binnen via web-to-lead, wordt toegewezen en geconverteerd. De opportunity krijgt producten uit het prijsboek, er wordt een offerte gemaakt en goedgekeurd, de deal wordt gewonnen, en de order of het contract gaat naar het volgende team of systeem.
• Case management. Een case komt binnen via email-to-case of het portal, wordt naar de juiste wachtrij of medewerker gerouteerd, volgt zijn entitlement en milestones, wordt opgelost met een kennisartikel, zo nodig geëscaleerd, en gesloten.

Knip elk proces op in testcases van elk één bedrijfsscenario, zoals Lead converteren met een bestaand account. Controleer daarna of elke user story in scope minstens één testcase heeft.

Stappen die businesstesters begrijpen

Schrijf elke stap als een actie en een verwacht resultaat, in de woorden van de tester. Voeg testdata toe waar dat ertoe doet. Een tester moet nooit hoeven raden of een stap geslaagd is.

Prioriteit en risico

Niet elke testcase is even belangrijk. Markeer elke testcase als Must, Should of Could: Must is wat op dag één moet werken, zoals een offerte maken of een case routeren. Voeg het risico toe: wat het kost als dit na de go-live misgaat. Testers beginnen met Must en hoog risico, zodat de belangrijke tests gedaan zijn, ook als de tijd opraakt.

Voeg ook de unhappy paths toe: een verplicht veld dat leeg blijft, een korting boven de limiet, een gebruiker die een record niet mag zien.

In UAT StudioImporteer je testcases uit Excel met de kolommen Priority en Risk, of begin met de Salesforce-scripts in de templatebibliotheek, een add-on bij elk betaald pakket. Testers zien hun Must-testcases als eerste.

Testers

Kies mensen die het werk elke dag doen: verkopers, servicemedewerkers, en hun managers voor goedkeuringen, forecasts en rapporten. Neem testers uit elk team en elk land dat Salesforce gebruikt, want hun processen en prijsboeken verschillen.

Hoeveel tijd

Vraag de tijd per tester, niet per team, en spreek die af met hun manager. Plan de scripts zo dat elke tester weet hoeveel er te doen is. Houd tijd vrij voor hertesten na de fixes. Testers die ondertussen nog telefoon opnemen of bij klanten langsgaan, komen niet klaar.

Een kick-off

Begin met een korte kick-off: waarom hun test ertoe doet, hoe ze inloggen op de sandbox, hoe ze een resultaat vastleggen en hoe ze een issue melden. Laat elke tester tijdens de kick-off één keer inloggen. De meeste problemen met gebruikers en wachtwoorden komen dan aan het licht, niet op de testdag.

Eén testdag of een week

• Eén testdag, in één ruimte of één call, geeft focus en snelle antwoorden. Dat past bij een kleine scope en testers die moeilijk langer vrij te maken zijn.
• Verspreid over een week, in blokken van een paar uur, laat ruimte voor fixes en hertesten tussen de blokken. Dat past bij een go-live met veel processen.

Hoe dan ook: leg elke dag een tijd vast voor de triage.

Tijdens de UAT

Issues loggen

Een goed issue kan zonder overleg worden opgelost. Vraag testers om:

• De stap, wat ze verwachtten en wat er in plaats daarvan gebeurde.
• Een screenshot van de pagina.
• De link naar het record. Die staat in de adresbalk van de browser en brengt de developer direct naar de opportunity of case waar het misging.
• De gebruiker waarmee ze testten, zodat het team weet welk profiel en welke permission sets zijn gebruikt.

In UAT StudioDe browserextensie voor Chrome en Edge toont de tests in een zijpaneel naast Salesforce. Een mislukte stap neemt de screenshot, de link naar het record en de foutmeldingen van de pagina mee. Een issue toont het record als link, inclusief sandbox.

Triage

Loop de nieuwe issues elke dag door, met de business en het Salesforce-team samen. Geef elk issue een ernst en iemand die het oplost, en besluit:

• Fix: een echt probleem, opgelost in deze release.
• Reject: Salesforce werkt zoals bedoeld, of de test was fout.
• Change request: een wens, geen defect. Die gaat naar de backlog, niet in deze release.

Hertest

Als een fix in de sandbox staat, test de tester die het issue vond de stap opnieuw. Noteer op welke build elke hertest is gedaan. Test na een grote fix ook de processen eromheen opnieuw.

Dagelijkse status

Stuur de stuurgroep elke dag een korte status: voortgang ten opzichte van de planning, open issues per ernst, en wat blokkeert. Houd het bij feiten. Geen verrassingen in het go/no-go-overleg.

In UAT StudioDe triage draait op een gedeeld scherm met Fix, Reject en Change request. Ready for retest mailt de hertester. Een dagoverzicht per e-mail, of in Microsoft Teams, toont de resultaten en de issues van de dag ervoor.

Sign-off en go/no-go

De UAT eindigt met een besluit van de business. Spreek de eindcriteria af vóór de eerste testdag, zodat niemand er aan het eind over discussieert:

• Er staat geen Critical issue open.
• Elke Must-testcase is geslaagd.
• Elk open High issue heeft een workaround of een datum voor de fix die de business accepteert.
• Elke testcase in scope heeft een resultaat.

Wie tekent

De eigenaar van elk proces geeft de sign-off, zoals de salesdirecteur voor lead to cash en het hoofd klantenservice voor case management. Die kiest: geaccepteerd, geaccepteerd met voorwaarden, of afgewezen. Noteer elke voorwaarde, met wie hem uitvoert en wanneer. Daarna besluit de stuurgroep over de go-live.

Wat er in het rapport komt

• Wat er in scope was, en wat niet is getest.
• De resultaten per proces of team, en per prioriteit.
• De sandbox, release en build die zijn getest.
• De open issues per ernst, met het besluit per issue.
• De sign-offs, met hun voorwaarden, en de bekende risico's voor de eerste weken.

In UAT StudioSign-off per groep: Accepted, Accepted with conditions of Rejected. Standaard kan niemand accepteren zolang er een Critical issue open staat. Het go/no-go-rapport staat klaar als PDF of als slides zodra het laatste resultaat binnen is.

Een regressieronde voor elke Salesforce-release

Na de go-live blijven de releases komen: drie per jaar. Elke release kan een pagina, een flow of een recht veranderen. Je UAT-testcases zijn de beste regressietest die je hebt, want ze beschrijven precies wat de business heeft geaccepteerd.

• Bewaar de testcases na de go-live, met hun stappen, testdata en verwachte resultaten.
• Lees de release notes van de komende release, en controleer welke functies automatisch voor je worden aangezet.
• Controleer of je UAT-sandbox in de sandbox preview zit, en plan de ronde in het preview-venster.
• Test de Must-testcases opnieuw, en Should als er tijd is, met een paar testers uit de business.
• Meld issues zoals in de UAT, en los ze op voordat de release productie bereikt.

In UAT StudioKies Salesforce als CRM van het project. De projectenpagina toont dan de komende Salesforce-releases, met de datum van de sandbox preview, de datum van productie en de release notes. Start a regression round kopieert de testcases die je kiest: Must and Should, Only Must of All test cases in scope.

Gratis te gebruiken

Voor alles wat je vóór, tijdens en na de UAT regelt, zie de UAT-checklist voor een CRM-go-live, ook als gratis Excel-bestand. Wat UAT Studio doet voor een Salesforce-UAT, lees je op Salesforce UAT.

Salesforce, Sales Cloud en Service Cloud zijn handelsmerken van Salesforce, Inc. UAT Studio is niet gelieerd aan of goedgekeurd door Salesforce.