UAT Dynamics 365: una guida pratica

Quando serve un UAT in Dynamics 365

Uno user acceptance test risponde a una sola domanda: il business riesce a svolgere il proprio lavoro in questa versione di Dynamics 365? Lo testano le persone che fanno quel lavoro, con parole loro, prima che arrivi in produzione. Ne serve uno in questi momenti.

• Un go-live. Il primo Dynamics 365 Sales o Customer Service, o il passaggio da un altro CRM.
• Una nuova app o un nuovo modulo. Customer Service accanto a Sales, una nuova app basata su modello per un team, un portale clienti o funzionalità di Copilot che attivi.
• Una modifica importante. Una nuova integrazione con l'ERP o un nuovo modo di instradare i casi.
• Gli aggiornamenti di Microsoft. Microsoft non raggruppa più le modifiche di Dynamics 365 in due release wave all'anno. Nuove funzionalità e modifiche arrivano durante tutto l'anno. I piani di rilascio sono stati archiviati a ottobre 2026; ciò che sta per arrivare si trova ora nella roadmap di Microsoft su aka.ms/AIatWorkRoadmap. Ogni aggiornamento può cambiare il funzionamento del tuo sistema, anche se tu non hai modificato nulla.

Un go-live richiede un UAT completo. Gli aggiornamenti richiedono un test di regressione più breve sui processi più importanti, con un ritmo fisso. Maggiori dettagli in Dopo il go-live.

Ambienti

Non testare mai in produzione. Nell'interfaccia di amministrazione di Power Platform, ogni ambiente ha un tipo. Per un UAT ti serve una sandbox.

Una copia della produzione

Il modo più vicino alla realtà è una copia della produzione in un ambiente sandbox. Quando copi un ambiente, scegli cosa portare con te:

• Tutto: le personalizzazioni, lo schema e tutti i dati. Il più vicino alla produzione, ma contiene dati reali dei clienti e ogni record creato dai tuoi utenti.
• Solo personalizzazioni e schemi: la configurazione senza i dati. Carichi i tuoi dati di test in un secondo momento.

Una copia sostituisce ciò che si trova nell'ambiente di destinazione, quindi falla prima dell'UAT, mai durante. Dopo, punta le integrazioni e i flussi di Power Automate verso i sistemi di test, non verso la produzione, controlla le caselle di posta e togli l'ambiente dalla modalità di amministrazione quando è pronto.

Soluzioni e build

Le modifiche del progetto arrivano nell'ambiente UAT come soluzioni. Importale come soluzioni gestite, tramite una pipeline se ne hai una, così l'ambiente UAT riceve esattamente ciò che riceverà in seguito la produzione.

• Concorda quando importare le soluzioni mentre i test sono in corso, per esempio una volta al giorno dopo il triage. Un'importazione nel mezzo di un test può cambiare la schermata sotto gli occhi di un tester.
• Annota quali soluzioni e versioni si trovano nell'ambiente UAT. Il numero di versione di una soluzione è la build che testi, e ogni anomalia e ogni retest appartengono a una build.

Dati di test

I tester perdono ore quando i dati non sono pronti. Preparali prima della prima giornata di test:

• Account e contatti per ogni tipo di cliente che testi, con il proprietario e la business unit giusti.
• Prodotti e listini prezzi. Un prodotto ha bisogno di una voce di listino prezzi prima di poter essere aggiunto al prezzo giusto, e deve essere pubblicato prima che i commerciali possano usarlo. Verifica che il listino prezzi di ogni team commerciale sia presente.
• Code, SLA e articoli della Knowledge Base per Customer Service: le code a cui vengono instradati i casi, SLA attivi e articoli pubblicati da trovare.
• Record aperti su cui lavorare: lead, opportunità in fasi diverse e casi aperti.
• Nessun dato personale reale dove puoi evitarlo. Una copia con Tutto li contiene tutti, quindi maschera o anonimizza ciò che i tester non devono vedere.

Ruoli di sicurezza, business unit e utenti per ruolo

Un UAT dimostra che ogni ruolo può svolgere il proprio lavoro, e solo quello. In Dynamics 365 questo dipende dai ruoli di sicurezza, dalla business unit e dai team di un utente. Anche le app vengono condivise tramite i ruoli di sicurezza: senza il ruolo giusto, un utente non vede nemmeno l'app.

• Elenca i ruoli che testi, come un commerciale, un responsabile commerciale, un operatore del servizio clienti e un supervisore del servizio clienti, con la loro business unit.
• Dai a ogni tester un utente con esattamente quel ruolo nell'ambiente UAT. Ogni utente ha bisogno di una licenza, anche in una sandbox.
• Quando una persona testa più ruoli, usa un utente di test separato per ogni ruolo, oppure cambia il ruolo tra un test e l'altro e annota quale è stato usato.
• Non testare mai con il ruolo Amministratore di sistema. Vede e può fare tutto, quindi nasconde proprio i problemi che un UAT dovrebbe trovare.

Cosa dire ai tester sull'ambiente

• L'indirizzo dell'ambiente UAT. Il solito segnalibro apre la produzione.
• Quale app aprire, come Hub delle vendite o l'area di lavoro Customer Service, e con quale account accedere.
• Che i dati sono dati di test: niente di ciò che fanno raggiunge un cliente reale, e niente di ciò che vedono è aggiornato.
• Chi chiamare quando non riescono ad accedere o non vedono l'app.

In UAT StudioOgni tester riceve un Test role, come il ruolo di sicurezza, e un Test account, mostrati in cima ai suoi test come Log in as …. Le Notes for testers contengono l'indirizzo dell'ambiente, le caselle email di test e chi chiamare. I tester accedono a UAT Studio con un codice via email oppure con Sign in with Microsoft.

Casi di test da user story e processi

Parti dai processi del business, non dalle tabelle in Dataverse. Due processi coprono gran parte di un UAT Dynamics 365:

• Dal lead all'opportunità all'offerta. Un lead arriva e viene qualificato in un account, un contatto e un'opportunità. L'opportunità segue il flusso di processo aziendale, riceve i prodotti dal listino prezzi, viene creata un'offerta che viene approvata e attivata, e la trattativa viene vinta e passa al team o al sistema successivo.
• Gestione dei casi. Un caso arriva via email o tramite il portale, viene instradato alla coda o all'operatore giusto, segue il suo SLA, viene risolto con un articolo della Knowledge Base, inoltrato a un livello superiore quando serve e chiuso.

Suddividi ogni processo in casi di test di un solo scenario di business ciascuno, come Qualificare un lead con un account esistente. Poi verifica che ogni user story nell'ambito abbia almeno un caso di test.

Flussi di processo aziendali

Un flusso di processo aziendale guida gli utenti attraverso delle fasi, con passaggi che possono essere obbligatori prima della fase successiva. Testalo come fa un utente:

• Ogni fase, e cosa succede quando un passaggio obbligatorio è vuoto.
• Ogni ramo, e ogni ruolo: un flusso può essere attivato solo per alcuni ruoli di sicurezza.

Instradamento, SLA e knowledge

In Customer Service, gran parte del lavoro avviene senza un clic. Testa ciò che il sistema dovrebbe fare da solo: un'email diventa un caso per l'account giusto, il caso finisce nella coda giusta, lo SLA mostra il tempo giusto e avvisa prima che scada, e l'operatore trova l'articolo della Knowledge Base giusto.

Passi comprensibili per i tester business

Scrivi ogni passo come un'azione e un risultato atteso, con le parole del tester. Aggiungi dati di test dove servono. Un tester non dovrebbe mai dover indovinare se un passo è stato superato.

Priorità e rischio

Non tutti i casi di test sono ugualmente importanti. Contrassegna ciascuno come Must, Should o Could: Must è ciò che deve funzionare dal primo giorno, come creare un'offerta o instradare un caso. Aggiungi il rischio: quanto costa se qualcosa va storto dopo il go-live. I tester iniziano da Must e rischio alto, così i test importanti vengono fatti anche quando il tempo finisce.

Aggiungi anche i percorsi negativi: un campo obbligatorio lasciato vuoto, uno sconto oltre il limite, un utente di un'altra business unit che non dovrebbe vedere un record.

In UAT StudioImporta i tuoi casi di test da Excel con le colonne Priority e Risk, leggili da Azure DevOps Test Plans, oppure parti dagli script Dynamics 365 della libreria di modelli, un modulo aggiuntivo per ogni piano a pagamento. Con la progettazione dei test con l'AI, l'AI propone casi di test dalle tue user story in Azure DevOps, anche sul modello della tua azienda, come Microsoft Foundry / Azure OpenAI. Niente diventa un caso di test finché non lo approvi.

Tester

Scegli persone che fanno quel lavoro ogni giorno: account manager, operatori del servizio clienti e i loro responsabili per approvazioni, code e dashboard. Prendi tester da ogni team e paese che usa Dynamics 365, perché i loro processi, business unit e listini prezzi sono diversi.

Quanto tempo

Concorda il tempo per tester con il loro responsabile e tieni del tempo per i retest. I tester che intanto rispondono alle chiamate o visitano i clienti non finiranno.

Un kick-off

Inizia con un breve kick-off: perché il loro test è importante, come aprire l'ambiente UAT, come registrare un risultato e come segnalare un'anomalia. Fai accedere ogni tester una volta durante il kick-off e fagli aprire l'app. La maggior parte dei problemi con licenze, ruoli e ambiente sbagliato emerge lì, non nella giornata di test.

Una giornata di test o una settimana

Una sola giornata di test dà concentrazione e risposte rapide, ed è adatta a un ambito ridotto. Una settimana a blocchi di qualche ora lascia spazio a nuove build e retest, ed è adatta a un go-live con molti processi. In entrambi i casi, fissa un orario per il triage ogni giorno.

Durante l'UAT

Registrare le anomalie

Una buona anomalia si può correggere senza una riunione. Chiedi ai tester:

• Il passo, cosa si aspettavano e cosa è successo invece.
• Uno screenshot della pagina, con il messaggio di errore se c'era.
• Il link al record. Si trova nella barra degli indirizzi del browser e porta il consulente direttamente all'opportunità o al caso in cui si è verificato il problema.
• L'utente e il ruolo di sicurezza con cui hanno testato.

In UAT StudioL'estensione del browser per Chrome ed Edge mostra i test in un pannello laterale accanto a Dynamics 365. Un passo fallito porta con sé lo screenshot, il link al record e i messaggi di errore della pagina. Il ruolo del tester è mostrato accanto al suo nome nell'anomalia.

Triage

Esamina le nuove anomalie ogni giorno, con il business e il team Dynamics 365 insieme. Assegna a ciascuna una gravità e qualcuno che la risolva, e decidi:

• Correggere: un problema reale, corretto in questa release.
• Rifiutare: Dynamics 365 funziona come previsto, oppure il test era sbagliato.
• Change request: un desiderio, non un difetto. Va nel backlog, non in questa release.

Invia agli sviluppatori le anomalie da correggere, spesso in Azure DevOps, con lo screenshot e il link al record.

Retest

Quando la correzione è in una nuova build nell'ambiente UAT, il tester che ha trovato l'anomalia ritesta il passo. Annota su quale build è stato fatto ogni retest. Dopo una correzione importante, testa di nuovo anche i processi intorno.

Stato giornaliero

Invia ogni giorno al comitato guida un breve stato: avanzamento rispetto al piano, anomalie aperte per gravità e cosa blocca. Nessuna sorpresa alla riunione go/no-go.

In UAT StudioIl triage si svolge su uno schermo condiviso con Fix, Reject e Change request. Un'anomalia diventa un work item di tipo Bug in Azure DevOps; quando lì è completato, l'anomalia diventa Ready for retest e il tester riceve un'email. Ogni round conserva la propria release, build e ambiente. Microsoft Teams riceve in un canale le nuove anomalie, i round e i sign-off.

Sign-off e go/no-go

L'UAT si conclude con una decisione del business. Concorda i criteri di uscita prima della prima giornata di test, così nessuno li discute alla fine:

• Nessuna anomalia Critical è aperta.
• Tutti i casi di test Must sono stati superati.
• Ogni anomalia High aperta ha un workaround o una data per la correzione che il business accetta.
• Ogni caso di test nell'ambito ha un risultato.

Chi firma

Il responsabile di ogni processo dà il sign-off, come il direttore commerciale per il processo dal lead all'offerta e il responsabile del servizio clienti per la gestione dei casi. Sceglie tra: accettato, accettato con condizioni o rifiutato. Annota ogni condizione, con chi se ne occupa ed entro quando. Poi il comitato guida decide sul go-live.

Cosa va nel report

• Cosa rientrava nell'ambito e cosa non è stato testato.
• I risultati per processo o team, e per priorità.
• L'ambiente, le soluzioni e la build che sono stati testati.
• Le anomalie aperte per gravità, con la decisione su ciascuna.
• I sign-off, con le loro condizioni, e i rischi noti per le prime settimane.

In UAT StudioSign-off per gruppo: Accepted, Accepted with conditions o Rejected. Per impostazione predefinita, nessuno può accettare finché è aperta un'anomalia Critical. Il report go/no-go è pronto in PDF o come slide non appena arriva l'ultimo risultato.

Round di regressione con un ritmo fisso

Dopo il go-live, gli aggiornamenti continuano ad arrivare, tutto l'anno, e ognuno può cambiare un modulo, un flusso o un'autorizzazione. I tuoi casi di test UAT sono il miglior test di regressione che hai: descrivono esattamente ciò che il business ha accettato.

• Scegli un ritmo, per esempio un round di regressione ogni mese o ogni trimestre, e inserisci fin da ora le date nel calendario dei tester.
• Prima di ogni round, leggi la roadmap di Microsoft e i messaggi per i tuoi amministratori, e annota quali modifiche toccano i tuoi processi.
• Prova prima in un ambiente sandbox le funzionalità in anteprima o in accesso anticipato, prima che arrivino ai tuoi utenti.
• Testa di nuovo i casi di test Must, e Should se c'è tempo, con alcuni tester del business.
• Registra le anomalie come nell'UAT e correggile prima che la modifica arrivi ai tuoi utenti.

In UAT StudioScegli Dynamics 365 come CRM del progetto. Start a regression round copia i casi di test che scegli da un UAT precedente, con i loro passi, dati di test e risultati attesi: Must and Should, Only Must o All test cases in scope.

Gratuito

Per tutto ciò che va organizzato prima, durante e dopo l'UAT, vedi la checklist UAT per il go-live di un CRM, disponibile anche come file Excel gratuito. Per ciò che UAT Studio fa per un UAT Dynamics 365, vedi UAT Dynamics 365.

Microsoft, Dynamics 365, Power Platform, Azure DevOps e Microsoft Teams sono marchi del gruppo di società Microsoft. UAT Studio non è affiliato a Microsoft né approvato da Microsoft.