Dynamics 365 UAT: een praktische gids

Wanneer je een UAT in Dynamics 365 nodig hebt

Een acceptatietest beantwoordt één vraag: kan de business haar werk doen in deze versie van Dynamics 365? 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 Dynamics 365 Sales of Customer Service, of een overstap vanuit een ander CRM.
• Een nieuwe app of module. Customer Service naast Sales, een nieuwe modelgestuurde app voor een team, een klantportal, of Copilot-functies die je aanzet.
• Een grote wijziging. Een nieuwe koppeling met het ERP, of een nieuwe manier om cases te routeren.
• De updates van Microsoft. Microsoft bundelt wijzigingen in Dynamics 365 niet meer in twee releasewaves per jaar. Nieuwe functies en wijzigingen worden het hele jaar door uitgerold. De releaseplannen zijn in oktober 2026 gearchiveerd; wat eraan komt, staat nu in de Microsoft-roadmap op aka.ms/AIatWorkRoadmap. Elke update kan veranderen hoe je systeem werkt, ook als je zelf niets hebt veranderd.

Een go-live vraagt om een volledige UAT. De updates vragen om een kortere regressietest van de processen die het meest tellen, in een vast ritme. Meer daarover onder Na de go-live.

Omgevingen

Test nooit in productie. In het Power Platform-beheercentrum heeft elke omgeving een type. Voor een UAT wil je een sandbox.

Een kopie van productie

Het dichtst bij de praktijk kom je met een kopie van productie in een sandboxomgeving. Als je een omgeving kopieert, kies je wat er meekomt:

• Alles: de aanpassingen, het schema en alle data. Het dichtst bij productie, maar er zitten echte klantgegevens in en elk record dat je gebruikers hebben gemaakt.
• Alleen aanpassingen en schema's: de configuratie zonder de data. Je laadt daarna je eigen testdata.

Een kopie vervangt wat er in de doelomgeving staat, dus maak hem vóór de UAT, nooit tijdens. Laat daarna koppelingen en Power Automate-stromen naar testsystemen wijzen, niet naar productie, controleer de mailboxen, en haal de omgeving uit de beheermodus als hij klaar is.

Oplossingen en de build

De wijzigingen van het project komen als oplossingen in de UAT-omgeving. Importeer ze als beheerde oplossingen, via een pijplijn als je die hebt, zodat de UAT-omgeving precies krijgt wat productie later krijgt.

• Spreek af wanneer oplossingen worden geïmporteerd terwijl er getest wordt, bijvoorbeeld één keer per dag na de triage. Een import midden in een test kan het scherm onder een tester veranderen.
• Noteer welke oplossingen en versies in de UAT-omgeving staan. Het versienummer van een oplossing is de build die je test, en elk issue en elke hertest hoort bij een build.

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 en bedrijfseenheid.
• Producten en prijslijsten. Een product heeft een prijslijstitem nodig voordat het tegen de juiste prijs kan worden toegevoegd, en het moet gepubliceerd zijn voordat verkopers het kunnen gebruiken. Controleer of de prijslijst van elk salesteam er is.
• Wachtrijen, SLA's en kennisartikelen voor Customer Service: de wachtrijen waarnaar cases worden gerouteerd, actieve SLA's, en gepubliceerde artikelen om te vinden.
• Open records om aan te werken: leads, opportunities in verschillende fasen en open cases.
• Geen echte persoonsgegevens waar je dat kunt vermijden. Een kopie met Alles bevat ze allemaal, dus maskeer of anonimiseer wat testers niet hoeven te zien.

Beveiligingsrollen, bedrijfseenheden en gebruikers per rol

Een UAT bewijst dat elke rol zijn werk kan doen, en alleen zijn werk. In Dynamics 365 hangt dat af van de beveiligingsrollen, de bedrijfseenheid en de teams van een gebruiker. Ook apps worden gedeeld via beveiligingsrollen: zonder de juiste rol ziet een gebruiker de app niet eens.

• Zet de rollen op een rij die je test, zoals een verkoper, een salesmanager, een servicemedewerker en een servicesupervisor, met hun bedrijfseenheid.
• Geef elke tester een gebruiker met precies die rol in de UAT-omgeving. Elke gebruiker heeft een licentie nodig, ook in een sandbox.
• Als één persoon meerdere rollen test, gebruik dan een aparte testgebruiker per rol, of wissel de rol tussen tests en noteer welke is gebruikt.
• Test nooit met de rol Systeembeheerder. Die ziet en mag alles, en verbergt dus precies de problemen die een UAT moet vinden.

Wat je testers vertelt over de omgeving

• Het adres van de UAT-omgeving. De gewone bladwijzer opent productie.
• Welke app ze openen, zoals Sales Hub of Customer Service-werkruimte, en met welk account ze inloggen.
• 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 of de app niet zien.

In UAT StudioElke tester krijgt een Test role, zoals de beveiligingsrol, en een Test account, bovenaan hun tests getoond als Log in as …. In de Notes for testers staan het adres van de omgeving, testmailboxen en wie ze kunnen bellen. Testers loggen in op UAT Studio met een code per e-mail, of met Sign in with Microsoft.

Testcases uit user stories en processen

Begin bij de processen van de business, niet bij de tabellen in Dataverse. Twee processen dekken het grootste deel van een Dynamics 365-UAT:

• Van lead via opportunity naar offerte. Een lead komt binnen en wordt gekwalificeerd tot een account, een contactpersoon en een opportunity. De opportunity volgt de bedrijfsprocesstroom, krijgt producten uit de prijslijst, er wordt een offerte gemaakt, goedgekeurd en geactiveerd, en de deal wordt gewonnen en gaat naar het volgende team of systeem.
• Case management. Een case komt binnen per e-mail of via het portal, wordt naar de juiste wachtrij of medewerker gerouteerd, volgt zijn SLA, wordt opgelost met een kennisartikel, zo nodig geëscaleerd, en afgesloten.

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

Bedrijfsprocesstromen

Een bedrijfsprocesstroom leidt gebruikers door fasen, met stappen die verplicht kunnen zijn voordat de volgende fase komt. Test hem zoals een gebruiker dat doet:

• Elke fase, en wat er gebeurt als een verplichte stap leeg is.
• Elke vertakking, en elke rol: een stroom kan voor alleen bepaalde beveiligingsrollen zijn ingeschakeld.

Routering, SLA's en kennis

In Customer Service gebeurt veel werk zonder klik. Test wat het systeem zelf moet doen: een e-mail wordt een case voor het juiste account, de case komt in de juiste wachtrij, de SLA toont de juiste tijd en waarschuwt voordat die verloopt, en de medewerker vindt het juiste kennisartikel.

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 in een andere bedrijfseenheid die een record niet mag zien.

In UAT StudioImporteer je testcases uit Excel met de kolommen Priority en Risk, lees ze in uit Azure DevOps Test Plans, of begin met de Dynamics 365-scripts in de templatebibliotheek, een add-on bij elk betaald pakket. Met AI test design stelt AI testcases voor op basis van je user stories in Azure DevOps, ook op het eigen model van je bedrijf, zoals Microsoft Foundry / Azure OpenAI. Niets wordt een testcase tot jij het goedkeurt.

Testers

Kies mensen die het werk elke dag doen: accountmanagers, servicemedewerkers, en hun managers voor goedkeuringen, wachtrijen en dashboards. Neem testers uit elk team en elk land dat Dynamics 365 gebruikt, want hun processen, bedrijfseenheden en prijslijsten verschillen.

Hoeveel tijd

Spreek de tijd per tester af met hun manager, en houd tijd vrij voor hertesten. 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 de UAT-omgeving openen, hoe ze een resultaat vastleggen en hoe ze een issue melden. Laat elke tester tijdens de kick-off één keer inloggen en de app openen. De meeste problemen met licenties, rollen en de verkeerde omgeving komen dan aan het licht, niet op de testdag.

Eén testdag of een week

Eén testdag geeft focus en snelle antwoorden, en past bij een kleine scope. Een week in blokken van een paar uur laat ruimte voor nieuwe builds en hertesten, en 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, met de foutmelding als die er was.
• De link naar het record. Die staat in de adresbalk van de browser en brengt de consultant direct naar de opportunity of case waar het misging.
• De gebruiker en de beveiligingsrol waarmee ze testten.

In UAT StudioDe browserextensie voor Chrome en Edge toont de tests in een zijpaneel naast Dynamics 365. Een mislukte stap neemt de screenshot, de link naar het record en de foutmeldingen van de pagina mee. Het issue toont de rol van de tester naast de naam.

Triage

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

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

Stuur de issues die opgelost moeten worden naar de developers, vaak in Azure DevOps, met de screenshot en de link naar het record.

Hertest

Als de fix in een nieuwe build in de UAT-omgeving 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. Geen verrassingen in het go/no-go-overleg.

In UAT StudioDe triage draait op een gedeeld scherm met Fix, Reject en Change request. Een issue wordt een werkitem van het type Bug in Azure DevOps; als het daar klaar is, staat het issue op Ready for retest en krijgt de tester een e-mail. Elke ronde bewaart zijn release, build en omgeving. Nieuwe issues, rondes en sign-offs komen in een kanaal in Microsoft Teams.

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 tot offerte 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 omgeving, de oplossingen en de 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.

Regressierondes in een vast ritme

Na de go-live blijven de updates komen, het hele jaar door, en elke update kan een formulier, een stroom of een recht veranderen. Je UAT-testcases zijn de beste regressietest die je hebt: ze beschrijven precies wat de business heeft geaccepteerd.

• Kies een ritme, bijvoorbeeld elke maand of elk kwartaal een regressieronde, en zet de datums nu al in de agenda van de testers.
• Lees vóór elke ronde de Microsoft-roadmap en de berichten voor je beheerders, en noteer welke wijzigingen je processen raken.
• Probeer functies in preview of vroege toegang eerst uit in een sandboxomgeving, voordat ze je gebruikers bereiken.
• 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 wijziging je gebruikers bereikt.

In UAT StudioKies Dynamics 365 als CRM van het project. Start a regression round kopieert de testcases die je kiest uit een eerdere UAT, met hun stappen, testdata en verwachte resultaten: 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 Dynamics 365-UAT, lees je op Dynamics 365 UAT.

Microsoft, Dynamics 365, Power Platform, Azure DevOps en Microsoft Teams zijn handelsmerken van de Microsoft-groep. UAT Studio is niet gelieerd aan of goedgekeurd door Microsoft.