UAT Salesforce: una guida pratica

Quando serve un UAT in Salesforce

Uno user acceptance test risponde a una sola domanda: il business riesce a svolgere il proprio lavoro in questa versione di Salesforce? 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 Sales Cloud o Service Cloud, o il passaggio da un altro CRM.
• Un nuovo cloud o una modifica importante. L'aggiunta di Service Cloud accanto a Sales Cloud, CPQ, una nuova integrazione con l'ERP o un nuovo modo di assegnare i case.
• Ogni release di Salesforce. Salesforce ha tre release all'anno: Spring, Summer e Winter. La release Winter arriva in autunno e porta il numero dell'anno successivo. Ogni release può cambiare il funzionamento della tua org, anche se tu non hai modificato nulla.
• La sandbox preview. Le sandbox su un'istanza di preview ricevono la nuova release alcune settimane prima della produzione. È la tua finestra per testare. Prima di ogni release, Salesforce pubblica quali istanze sono nella preview e cosa fare per mantenervi una sandbox. Controllalo per tempo, perché un refresh può spostare una sandbox dentro o fuori dalla preview.

Un go-live richiede un UAT completo. Una release richiede un test di regressione più breve sui processi più importanti. Maggiori dettagli in Dopo il go-live.

La sandbox

Non testare mai in produzione. Salesforce ha quattro tipi di sandbox. Due sono adatti a un UAT.

Pianifica il refresh

Un refresh sostituisce tutto il contenuto della sandbox con una nuova copia della produzione. Ogni tipo di sandbox ha un intervallo minimo tra un refresh e l'altro, e la sandbox Full ha il più lungo. Quindi pianificalo:

• Fai il refresh prima dell'UAT, mai durante. Controlla quando sarà possibile il prossimo refresh della sandbox.
• Rilascia la release nella sandbox dopo il refresh. Il lavoro che esisteva solo nella sandbox va perso.
• Esegui i passaggi successivi a un refresh: punta le integrazioni e le credenziali denominate verso i sistemi di test, non verso la produzione, e disattiva i job pianificati che non devono essere eseguiti.
• Controlla il recapito delle email. Una sandbox nuova o appena aggiornata invia solo email di sistema. Le risposte Web-to-Lead, le approvazioni e le email dei case richiedono di più, ma una sandbox Full contiene i veri indirizzi email dei tuoi referenti. Usa indirizzi di test prima di aprirla.

Dati di test

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

• Account e referenti per ogni tipo di cliente che testi, con il titolare, la regione e il tipo di record giusti.
• Prodotti e listini prezzi. Un prodotto deve avere un prezzo nel listino prezzi standard prima di poter stare in un altro listino prezzi. Verifica che i listini prezzi di ogni team commerciale siano attivi.
• Record aperti su cui lavorare: opportunità in fasi diverse, case aperti e case vicini a una milestone se testi i diritti.
• Nessun dato personale reale dove puoi evitarlo. Una sandbox Full copia tutto, quindi maschera o anonimizza ciò che i tester non devono vedere.

Utenti per profilo e set di autorizzazioni

Un UAT dimostra che ogni ruolo può svolgere il proprio lavoro, e solo quello. Crea un utente di test per ogni combinazione di profilo, ruolo e set di autorizzazioni che testi, come un commerciale, un responsabile commerciale e un operatore del servizio clienti. Ogni tester ha il proprio utente, così due persone non lavorano mai contemporaneamente con lo stesso utente.

Dopo un refresh, Salesforce aggiunge il nome della sandbox a ogni nome utente e .invalid all'indirizzo email di ogni utente. Imposta come email di ogni utente di test un indirizzo che il tester legge, altrimenti le email di reimpostazione della password e di approvazione non arrivano a nessuno.

Log in as permette a un amministratore di vedere Salesforce con gli occhi di un altro utente. È un buon modo per esaminare un problema segnalato da un tester. Per il test vero e proprio, i tester usano il proprio utente di test: è così che sai che il profilo e i set di autorizzazioni sono corretti.

Cosa dire ai tester sulla sandbox

• L'indirizzo della sandbox. Contiene il nome della sandbox, oppure si accede tramite test.salesforce.com. La normale pagina di accesso di Salesforce apre la produzione.
• Il loro nome utente, che termina con il nome della sandbox, e come ricevono la password.
• 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, prima di perdere una mattinata.

In UAT StudioOgni tester riceve un Test role e un Test account, mostrati in cima ai suoi test come Log in as …. Le Notes for testers contengono l'indirizzo della sandbox, le caselle email di test e chi chiamare.

Casi di test da user story e processi

Parti dai processi del business, non dagli oggetti di Salesforce. Due processi coprono gran parte di un UAT Salesforce:

• Lead to cash. Un lead arriva tramite Web-to-Lead, viene assegnato e convertito. L'opportunità riceve i prodotti dal listino prezzi, viene creato e approvato un preventivo, la trattativa viene vinta e l'ordine o il contratto passa al team o al sistema successivo.
• Gestione dei case. Un case arriva tramite Email-to-Case o il portale, viene assegnato alla coda o all'operatore giusto, segue il suo diritto e le sue milestone, viene risolto con un articolo Knowledge, inoltrato a un livello superiore quando serve e chiuso.

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

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 preventivo o assegnare un case. 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 che non dovrebbe vedere un record.

In UAT StudioImporta i tuoi casi di test da Excel con le colonne Priority e Risk, oppure parti dagli script Salesforce della libreria di modelli, un modulo aggiuntivo per ogni piano a pagamento. I tester vedono per primi i loro casi di test Must.

Tester

Scegli persone che fanno quel lavoro ogni giorno: commerciali, operatori del servizio clienti e i loro responsabili per approvazioni, previsioni e report. Prendi tester da ogni team e paese che usa Salesforce, perché i loro processi e listini prezzi sono diversi.

Quanto tempo

Chiedi il tempo per tester, non per team, e fallo approvare dal loro responsabile. Pianifica gli script in modo che ogni tester sappia quanto c'è da fare. Tieni del tempo per i retest dopo le correzioni. 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 accedere alla sandbox, come registrare un risultato e come segnalare un'anomalia. Fai accedere ogni tester una volta durante il kick-off. La maggior parte dei problemi con utenti e password emerge lì, non nella giornata di test.

Una giornata di test o una settimana

• Una giornata di test, in una sola stanza o in una sola call, dà concentrazione e risposte rapide. È adatta a un ambito ridotto e a tester difficili da liberare più a lungo.
• Distribuito su una settimana, a blocchi di qualche ora, lascia spazio a correzioni e retest tra un blocco e l'altro. È adatto 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.
• Il link al record. Si trova nella barra degli indirizzi del browser e porta lo sviluppatore direttamente all'opportunità o al case in cui si è verificato il problema.
• L'utente con cui hanno testato, così il team sa quale profilo e quali set di autorizzazioni sono stati usati.

In UAT StudioL'estensione del browser per Chrome ed Edge mostra i test in un pannello laterale accanto a Salesforce. Un passo fallito porta con sé lo screenshot, il link al record e i messaggi di errore della pagina. Un'anomalia mostra il record come link, sandbox compresa.

Triage

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

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

Retest

Quando una correzione viene rilasciata nella sandbox, 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. Attieniti ai fatti. Nessuna sorpresa alla riunione go/no-go.

In UAT StudioIl triage si svolge su uno schermo condiviso con Fix, Reject e Change request. Ready for retest invia un'email a chi deve ritestare. Un riepilogo giornaliero via email, o in Microsoft Teams, mostra i risultati e le anomalie del giorno prima.

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 lead to cash e il responsabile del servizio clienti per la gestione dei case. 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à.
• La sandbox, la release e la build testate.
• 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.

Un round di regressione per ogni release di Salesforce

Dopo il go-live, le release continuano ad arrivare: tre all'anno. Ognuna può cambiare una pagina, un flow o un'autorizzazione. I tuoi casi di test UAT sono il miglior test di regressione che hai, perché descrivono esattamente ciò che il business ha accettato.

• Conserva i casi di test dopo il go-live, con i loro passi, dati di test e risultati attesi.
• Leggi le note di rilascio della prossima release e verifica quali funzionalità vengono attivate automaticamente per te.
• Verifica che la tua sandbox UAT sia nella sandbox preview e pianifica il round nella finestra di preview.
• 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 release arrivi in produzione.

In UAT StudioScegli Salesforce come CRM del progetto. La pagina dei progetti mostra allora le prossime release di Salesforce, con la data della sandbox preview, la data in produzione e le note di rilascio. Start a regression round copia i casi di test che scegli: 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 Salesforce, vedi UAT Salesforce.

Salesforce, Sales Cloud e Service Cloud sono marchi di Salesforce, Inc. UAT Studio non è affiliato a Salesforce né approvato da Salesforce.