Dynamics 365 UAT: en praktisk guide

När du behöver en UAT i Dynamics 365

Ett acceptanstest besvarar en fråga: kan verksamheten göra sitt arbete i den här versionen av Dynamics 365? De som gör arbetet testar det, med sina egna ord, innan det når produktion. Du behöver ett vid de här tillfällena.

• En go-live. Det första Dynamics 365 Sales eller Customer Service, eller en flytt från ett annat CRM.
• En ny app eller modul. Customer Service bredvid Sales, en ny modellbaserad app för ett team, en kundportal eller Copilot-funktioner som du slår på.
• En stor ändring. En ny integration med affärssystemet (ERP), eller ett nytt sätt att dirigera kundärenden.
• Uppdateringarna från Microsoft. Microsoft samlar inte längre ändringarna i Dynamics 365 i två lanseringsvågor per år. Nya funktioner och ändringar rullas ut under hela året. Lanseringsplanerna arkiverades i oktober 2026; det som är på väg finns nu i Microsofts översikt på aka.ms/AIatWorkRoadmap. Varje uppdatering kan ändra hur ditt system fungerar, även om du inte själv har ändrat något.

En go-live kräver en fullständig UAT. Uppdateringarna kräver ett kortare regressionstest av de processer som betyder mest, i en fast rytm. Mer om det under Efter go-live.

Miljöer

Testa aldrig i produktion. I Power Platform administrationscenter har varje miljö en typ. För en UAT vill du ha en sandbox.

En kopia av produktion

Det närmaste verkligheten du kommer är en kopia av produktion i en sandbox-miljö. När du kopierar en miljö väljer du vad som följer med:

• Allt: anpassningarna, schemat och alla data. Närmast produktion, men den innehåller riktiga kunddata och varje post som dina användare har skapat.
• Endast anpassningar och scheman: konfigurationen utan data. Du laddar in dina egna testdata efteråt.

En kopia ersätter det som finns i målmiljön, så gör den före UAT:n, aldrig under den. Peka efteråt integrationer och Power Automate-flöden mot testsystem, inte mot produktion, kontrollera brevlådorna och ta miljön ur administrationsläge när den är klar.

Lösningar och build

Projektets ändringar når UAT-miljön som lösningar. Importera dem som hanterade lösningar, via en pipeline om du har en, så att UAT-miljön får exakt det som produktion får senare.

• Kom överens om när lösningar importeras medan testningen pågår, till exempel en gång om dagen efter triagen. En import mitt i ett test kan ändra skärmen under en testare.
• Skriv ner vilka lösningar och versioner som finns i UAT-miljön. Versionsnumret på en lösning är den build du testar, och varje ärende och omtest hör till en build.

Testdata

Testare förlorar timmar när data inte är klara. Förbered dem före den första testdagen:

• Konton och kontakter för varje typ av kund du testar, med rätt ägare och affärsenhet.
• Produkter och prislistor. En produkt behöver ett prislisteobjekt innan den kan läggas till till rätt pris, och den måste publiceras innan säljarna kan använda den. Kontrollera att varje säljteams prislista finns.
• Köer, SLA:er och kunskapsartiklar för Customer Service: köerna som kundärenden dirigeras till, aktiva SLA:er och publicerade artiklar att hitta.
• Öppna poster att arbeta med: leads, affärsmöjligheter i olika faser och öppna kundärenden.
• Inga riktiga personuppgifter där du kan undvika det. En kopia med Allt innehåller allt detta, så maskera eller anonymisera det som testarna inte behöver se.

Säkerhetsroller, affärsenheter och användare per roll

En UAT visar att varje roll kan göra sitt arbete, och bara sitt arbete. I Dynamics 365 beror det på en användares säkerhetsroller, affärsenhet och team. Appar delas också via säkerhetsroller: utan rätt roll ser en användare inte ens appen.

• Lista de roller du testar, till exempel en säljare, en säljchef, en servicehandläggare och en kundtjänstansvarig, med deras affärsenhet.
• Ge varje testare en användare med exakt den rollen i UAT-miljön. Varje användare behöver en licens, även i en sandbox.
• När en person testar flera roller, använd en separat testanvändare per roll, eller byt roll mellan testerna och skriv ner vilken som användes.
• Testa aldrig med säkerhetsrollen System Administrator. Den ser och får göra allt, så den döljer just de problem som en UAT ska hitta.

Vad du ska berätta för testarna om miljön

• UAT-miljöns adress. Det vanliga bokmärket öppnar produktion.
• Vilken app de ska öppna, till exempel Sales Hub eller Customer Service workspace, och vilket konto de ska logga in med.
• Att data är testdata: inget de gör når en riktig kund, och inget de ser är aktuellt.
• Vem de ska ringa när de inte kan logga in eller inte ser appen.

I UAT StudioVarje testare får en Test role, till exempel säkerhetsrollen, och ett Test account, som visas överst i deras tester som Log in as …. Notes for testers innehåller miljöns adress, testbrevlådor och vem man ska ringa. Testarna loggar in i UAT Studio med en kod via e-post, eller med Sign in with Microsoft.

Testfall från user stories och processer

Utgå från verksamhetens processer, inte från tabellerna i Dataverse. Två processer täcker det mesta av en Dynamics 365-UAT:

• Lead till affärsmöjlighet till offert. En lead kommer in och kvalificeras till ett konto, en kontakt och en affärsmöjlighet. Affärsmöjligheten följer affärsprocessflödet, får produkter från prislistan, en offert tas fram, godkänns och aktiveras, och affären vinns och går vidare till nästa team eller system.
• Ärendehantering. Ett kundärende kommer in via e-post eller portalen, dirigeras till rätt kö eller handläggare, följer sitt SLA, löses med en kunskapsartikel, eskaleras vid behov och avslutas.

Dela upp varje process i testfall med ett affärsscenario vardera, till exempel Kvalificera en lead med ett befintligt konto. Kontrollera sedan att varje user story i omfattningen har minst ett testfall.

Affärsprocessflöden

Ett affärsprocessflöde leder användarna genom faser, med steg som kan vara obligatoriska före nästa fas. Testa det som en användare gör:

• Varje fas, och vad som händer när ett obligatoriskt steg är tomt.
• Varje gren, och varje roll: ett flöde kan slås på för bara vissa säkerhetsroller.

Dirigering, SLA:er och kunskap

I Customer Service sker mycket av arbetet utan ett klick. Testa det som systemet ska göra av sig självt: ett mejl blir ett kundärende för rätt konto, kundärendet hamnar i rätt kö, SLA:t visar rätt tid och varnar innan det löper ut, och handläggaren hittar rätt kunskapsartikel.

Steg som verksamhetstestare förstår

Skriv varje steg som en åtgärd och ett förväntat resultat, med testarens ord. Lägg till testdata där det spelar roll. En testare ska aldrig behöva gissa om ett steg gick igenom.

Prioritet och risk

Alla testfall är inte lika viktiga. Märk vart och ett med Must, Should eller Could: Must är det som måste fungera från dag ett, till exempel att skapa en offert eller dirigera ett kundärende. Lägg till risken: vad det kostar om det går fel efter go-live. Testarna börjar med Must och hög risk, så att de viktiga testerna blir gjorda även när tiden tar slut.

Lägg också till de olyckliga vägarna: ett obligatoriskt fält som lämnas tomt, en rabatt över gränsen, en användare i en annan affärsenhet som inte ska se en post.

I UAT StudioImportera dina testfall från Excel med kolumnerna Priority och Risk, läs in dem från Azure DevOps Test Plans, eller börja från Dynamics 365-skripten i mallbiblioteket, ett tillägg till alla betalda paket. Med AI test design föreslår AI testfall utifrån dina user stories i Azure DevOps, även på ditt företags egen modell, till exempel Microsoft Foundry / Azure OpenAI. Inget blir ett testfall förrän du godkänner det.

Testare

Välj personer som gör arbetet varje dag: kundansvariga, servicehandläggare och deras chefer för godkännanden, köer och instrumentpaneler. Ta testare från varje team och land som använder Dynamics 365, eftersom deras processer, affärsenheter och prislistor skiljer sig åt.

Hur mycket tid

Kom överens med deras chef om tiden per testare, och spara tid för omtester. Testare som samtidigt tar samtal eller besöker kunder blir inte klara.

En kick-off

Börja med en kort kick-off: varför deras test spelar roll, hur de öppnar UAT-miljön, hur de registrerar ett resultat och hur de registrerar ett ärende. Låt varje testare logga in en gång under kick-offen och öppna appen. De flesta problem med licenser, roller och fel miljö dyker upp där, inte på testdagen.

En testdag eller en vecka

En testdag ger fokus och snabba svar, och passar en liten omfattning. En vecka i block på några timmar ger utrymme för nya builds och omtester, och passar en go-live med många processer. Hur du än gör: bestäm en tid för triagen varje dag.

Under UAT:n

Registrera ärenden

Ett bra ärende kan åtgärdas utan ett möte. Be testarna om:

• Steget, vad de förväntade sig och vad som hände i stället.
• En skärmbild av sidan, med felmeddelandet om det fanns ett.
• Länken till posten. Den finns i webbläsarens adressfält och tar konsulten direkt till affärsmöjligheten eller kundärendet där det gick fel.
• Användaren och den säkerhetsroll de testade med.

I UAT StudioWebbläsartillägget för Chrome och Edge visar testerna i en sidopanel bredvid Dynamics 365. Ett misslyckat steg tar med skärmbilden, länken till posten och sidans felmeddelanden. Testarens roll visas bredvid namnet i ärendet.

Triage

Gå igenom de nya ärendena varje dag, med verksamheten och Dynamics 365-teamet tillsammans. Ge vart och ett en allvarlighetsgrad och någon som åtgärdar det, och besluta:

• Fix: ett verkligt problem, som åtgärdas i den här releasen.
• Reject: Dynamics 365 fungerar som det är tänkt, eller så var testet fel.
• Change request: ett önskemål, inte ett fel. Det går till backloggen, inte in i den här releasen.

Skicka ärendena som ska åtgärdas till utvecklarna, ofta i Azure DevOps, med skärmbilden och länken till posten.

Omtest

När rättningen finns i en ny build i UAT-miljön testar testaren som hittade ärendet steget igen. Skriv upp vilken build varje omtest gjordes på. Efter en stor rättning testar du också processerna runt omkring igen.

Daglig status

Skicka en kort status till styrgruppen varje dag: framsteg mot planen, öppna ärenden efter allvarlighetsgrad och vad som blockerar. Inga överraskningar på go/no-go-mötet.

I UAT StudioTriagen körs på en delad skärm med Fix, Reject och Change request. Ett ärende blir ett Bug-arbetsobjekt i Azure DevOps; när det är klart där blir ärendet Ready for retest och testaren får ett mejl. Varje runda behåller sin release, build och miljö. Microsoft Teams får nya ärenden, rundor och godkännanden i en kanal.

Godkännande och go/no-go

UAT:n avslutas med ett beslut av verksamheten. Kom överens om slutkriterierna före den första testdagen, så att ingen bråkar om dem i slutet:

• Inget Critical-ärende är öppet.
• Alla Must-testfall har gått igenom.
• Varje öppet High-ärende har en tillfällig lösning eller ett datum för rättningen som verksamheten accepterar.
• Varje testfall som ingår har ett resultat.

Vem som skriver under

Ägaren till varje process ger sitt godkännande, till exempel försäljningsdirektören för lead till offert och chefen för kundservice för ärendehantering. De väljer: godkänt, godkänt med villkor eller avvisat. Skriv upp varje villkor, med vem som gör det och när. Styrgruppen beslutar sedan om go-live.

Vad som ska stå i rapporten

• Vad som ingick i omfattningen, och vad som inte testades.
• Resultaten per process eller team, och per prioritet.
• Miljön, lösningarna och den build som testades.
• De öppna ärendena efter allvarlighetsgrad, med beslutet för vart och ett.
• Godkännandena, med deras villkor, och de kända riskerna för de första veckorna.

I UAT StudioGodkännande per grupp: Accepted, Accepted with conditions eller Rejected. Som standard kan ingen godkänna medan ett Critical-ärende är öppet. Go/no-go-rapporten är klar som PDF eller som bilder när det sista resultatet har kommit in.

Regressionsrundor i en fast rytm

Efter go-live fortsätter uppdateringarna att komma, under hela året, och var och en kan ändra ett formulär, ett flöde eller en behörighet. Dina UAT-testfall är det bästa regressionstest du har: de beskriver exakt vad verksamheten har godkänt.

• Välj en rytm, till exempel en regressionsrunda varje månad eller varje kvartal, och lägg in datumen i testarnas kalender redan nu.
• Läs Microsofts översikt och meddelandena till dina administratörer före varje runda, och anteckna vilka ändringar som berör dina processer.
• Prova funktioner i förhandsversion eller tidig åtkomst i en sandbox-miljö först, innan de når dina användare.
• Testa Must-testfallen igen, och Should om det finns tid, med några testare från verksamheten.
• Registrera ärenden som i UAT:n, och åtgärda dem innan ändringen når dina användare.

I UAT StudioVälj Dynamics 365 som projektets CRM. Start a regression round kopierar de testfall du väljer från en tidigare UAT, med deras steg, testdata och förväntade resultat: Must and Should, Only Must eller All test cases in scope.

Gratis att använda

För allt som ska ordnas före, under och efter UAT:n, se UAT-checklistan för en CRM-go-live, även som en gratis Excel-fil. För vad UAT Studio gör för en Dynamics 365-UAT, se Dynamics 365 UAT.

Microsoft, Dynamics 365, Power Platform, Azure DevOps och Microsoft Teams är varumärken som tillhör Microsoft-koncernen. UAT Studio är inte anknutet till eller godkänt av Microsoft.