Test di regressione dopo una release del CRM

Perché un CRM ha bisogno di test di regressione

Dopo il go-live il tuo CRM continua a cambiare, anche quando il tuo team non cambia nulla. Salesforce e Microsoft aggiornano la piattaforma per ogni cliente. La maggior parte delle modifiche sono miglioramenti. Alcune cambiano una pagina, un'impostazione predefinita o il modo in cui funziona una funzionalità, e ogni tanto una rompe qualcosa su cui il tuo business fa affidamento.

Un test di regressione risponde a una sola domanda: ciò che il business ha accettato al go-live funziona ancora? Non è un nuovo UAT. È un controllo breve e mirato dei processi che contano di più, fatto prima che la modifica raggiunga i tuoi utenti, da persone che conoscono il lavoro.

Le tue release hanno bisogno dello stesso controllo. Una nuova integrazione, un nuovo campo nel preventivo, una modifica all'instradamento dei casi: ognuna può toccare qualcosa che prima funzionava.

Salesforce: tre release all'anno

Salesforce ha tre release principali all'anno: Spring, Summer e Winter. La release Winter arriva in autunno e porta il numero dell'anno successivo. Ogni org viene aggiornata, in date che Salesforce pubblica in anticipo.

• 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 indica quali istanze sono nella preview e cosa fare per mantenervi una sandbox. Un refresh può spostare una sandbox dentro o fuori dalla preview, quindi verificalo per tempo.
• Le note di rilascio. Leggile per i cloud e le funzionalità che usi. Cerca cosa viene attivato automaticamente per te e cosa cambia l'aspetto delle pagine in cui lavorano i tuoi utenti.
• Release update. Alcune modifiche vengono annunciate in Setup con una data in cui diventano obbligatorie. Testale nella sandbox prima di quella data, così non ti sorprendono in produzione.

Per Salesforce, quindi, il ritmo è dato: un round di regressione nella finestra di preview di ogni release, tre volte all'anno.

In UAT StudioScegli Salesforce come CRM del progetto. Da circa due mesi prima di una release, la pagina dei progetti mostra Coming CRM releases, con la data della sandbox preview, la data in produzione e un link alle note di rilascio. Salesforce può ancora spostare queste date, quindi controlla le note di rilascio.

Dynamics 365: aggiornamenti tutto l'anno

Microsoft non raggruppa più le modifiche di Dynamics 365 in due release wave all'anno. Nuove funzionalità e modifiche vengono distribuite durante tutto l'anno. I piani di rilascio sono stati archiviati a ottobre 2026; ciò che arriva è ora nella roadmap Microsoft su aka.ms/AIatWorkRoadmap.

Questo significa che non c'è più un unico grande momento all'anno attorno a cui pianificare i test. Le modifiche arrivano a piccoli passi, più spesso. Aspettare una grande release non funziona più, e testare dopo ogni singola modifica è troppo.

Scegli un ritmo fisso

La risposta è un round di regressione con un ritmo fisso, qualunque cosa Microsoft rilasci nel frattempo:

• Ogni mese quando il CRM è centrale per il business, usi molte app e funzionalità, o attivi spesso nuove funzionalità.
• Ogni trimestre per una configurazione stabile con poche modifiche tue.
• Un round extra prima che una tua modifica vada in produzione, o quando una modifica di Microsoft tocca chiaramente uno dei tuoi processi chiave.

Metti le date nel calendario dei tester per tutto l'anno. Un ritmo fisso è più facile da mantenere di un round pianificato ogni volta che salta fuori qualcosa.

Prima di ogni round

• Leggi la roadmap Microsoft e i messaggi per i tuoi amministratori nell'interfaccia di amministrazione di Microsoft 365, e annota quali modifiche toccano i tuoi processi.
• Prova prima le funzionalità in anteprima in un ambiente sandbox, prima che raggiungano i tuoi utenti.
• Assicurati che la sandbox in cui testi abbia la stessa versione e le stesse soluzioni della produzione.

In UAT StudioScegli Dynamics 365 come CRM del progetto e avvia ogni round con Start a regression round, dal progetto del tuo go-live o del tuo ultimo round.

In UAT StudioIn Setup, scegli Check the Dynamics 365 updates: Every quarter o Every month. La pagina dei progetti mostra allora il periodo corrente con un link alla roadmap, e gli amministratori ricevono una email per periodo, due settimane prima che inizi.

Scegliere cosa ritestare

Un round di regressione non è il luogo per ritestare tutto. Scegli, in quest'ordine:

1. I casi di test Must. Ciò che deve funzionare ogni giorno: creare un preventivo, convertire un lead, instradare un caso, le approvazioni. Testali a ogni round.
2. Ciò che la modifica tocca. Leggi le note di rilascio o la roadmap con accanto l'elenco dei tuoi processi. Una modifica ai preventivi significa i casi di test dei preventivi, anche quelli Should e Could.
3. Integrazioni e automazioni. I collegamenti con l'ERP, il sito web o l'email, e i flussi che girano in background. Si rompono in silenzio, quindi testali di proposito.
4. I casi di test Should, quando c'è tempo.

Poi guarda cosa ha cambiato il tuo team dall'ultimo round. Tutto ciò che hai costruito tu e che nessuno ha testato insieme alla modifica della piattaforma rientra anch'esso nel round.

Tieni un breve elenco di ciò che è critico

Scrivi, una volta, i dieci-venti processi di cui il business non può fare a meno nemmeno per un giorno. Sono il nucleo di ogni round di regressione. Rivedi l'elenco ogni sei mesi con i responsabili dei processi, e dopo ogni grande modifica tua.

In UAT StudioCon il modulo aggiuntivo Release readiness, Review the release mostra quali casi di test tocca una release di Salesforce o un aggiornamento di Dynamics 365, con il motivo, propone casi di test per ciò che non è ancora coperto ed elenca gli aggiornamenti obbligatori con le loro date. Il round di regressione riceve allora esattamente i casi di test Must, quelli toccati che tieni e quelli nuovi che approvi. Un fail nel round indica con quale modifica è arrivato. €99 al mese: aggiungilo in Plan & billing.

Riutilizza i tuoi casi di test

Il miglior test di regressione che hai è l'insieme dei casi di test dell'UAT del tuo go-live. Descrivono esattamente ciò che il business ha accettato, con i passi, i dati di test e i risultati attesi. Non scriverne di nuovi per ogni round.

• Conserva i casi di test dopo il go-live, in un unico posto, con la loro priorità.
• Aggiornali quando cambia il tuo processo, così il round successivo testa il CRM com'è adesso, non com'era al go-live.
• Controlla i dati di test prima di ogni round. Un refresh della sandbox o una copia della produzione può eliminare o modificare i record usati dai casi di test.
• Aggiungi un caso di test per ogni anomalia grave trovata in produzione, così la prossima volta viene intercettata.

Qui vale la pena investire in casi di test che i tester business possono seguire: vengono riutilizzati più e più volte. Vedi Scrivere casi di test comprensibili per i tester business.

In UAT StudioStart a regression round copia i casi di test del progetto da cui parti, con i loro passi, dati di test e risultati attesi. Scegli quali portare con te: Must and Should, Only Must o All test cases in scope; un caso di test senza priorità conta come Should. Il nuovo progetto riceve i gruppi e le impostazioni, e inviti i tester in Setup. Nulla viene inventato o modificato.

Chi testa, e quanto dura

Chi

Un round di regressione richiede meno persone di un UAT, ma dovrebbero comunque venire dal business. Chiedi uno o due key user per processo: persone che fanno il lavoro ogni giorno e si accorgono subito quando qualcosa non va. L'amministratore del CRM prepara il round e testa ciò che gira in background, ma non dovrebbe essere l'unico tester.

Fai testare le stesse persone round dopo round. Diventano più veloci e notano piccoli cambiamenti che un nuovo tester non vedrebbe.

Durata

• Preparazione: un giorno o due per leggere le modifiche, scegliere i casi di test e controllare i dati di test.
• Test: qualche ora per tester, distribuita su uno o due giorni per un round mensile, fino a una settimana per una release di Salesforce con molte modifiche.
• Correzioni e retest: tieni qualche giorno prima che la modifica arrivi in produzione, per le anomalie che trovi.

Per Salesforce, tutto questo deve stare nella finestra di preview. Inizia presto nella finestra, non nell'ultima settimana.

Registrare ciò che trovi

Registra le anomalie come nell'UAT: il passo, cosa ti aspettavi, cosa è successo invece, uno screenshot e il link al record. Fanne il triage ogni giorno con il team CRM. Per un'anomalia causata dalla piattaforma, guarda prima nelle note di rilascio o nella roadmap: spesso è una modifica nota con un'impostazione da adattare.

In UAT StudioOgni round conserva la sua release, la build e l'ambiente, così il report go/no-go dice cosa è stato testato. Dopo le correzioni, Start round 2 nella dashboard con Failed and blocked only ritesta solo ciò che è andato storto; i risultati del round precedente vengono conservati.

Sign-off prima della produzione

Un round di regressione termina come un UAT, con una decisione, solo più breve. Concorda i criteri di uscita una volta e usali a ogni round:

• Tutti i casi di test Must sono stati superati.
• Nessuna anomalia Critical è aperta.
• Ogni anomalia High aperta ha un workaround che il business accetta, oppure una correzione prima che la modifica arrivi in produzione.

Il responsabile di ogni processo dà il sign-off per la sua parte: accettato, accettato con condizioni o rifiutato. Per una release di Salesforce non puoi fermare l'aggiornamento, quindi un rifiuto significa una correzione o un workaround prima della data in produzione, e un messaggio agli utenti. Per una tua modifica, un rifiuto significa che aspetta.

Conserva il risultato di ogni round. Dopo un anno hai una traccia chiara di ciò che è stato testato dopo ogni modifica, e di chi l'ha accettato. Per come preparare la decisione, vedi La decisione go/no-go.

In UAT StudioUn round di regressione è un progetto a sé, con la release come sua Release, così il suo report go/no-go dice di quale release del CRM si tratta. I responsabili dei processi danno il sign-off per gruppo, e il sign-off appartiene a quel round.

Gratuito

La checklist UAT per il go-live di un CRM funziona anche per un round di regressione, come file Excel gratuito. Per ogni piattaforma, vedi UAT Salesforce e UAT Dynamics 365.

Salesforce è un marchio di Salesforce, Inc. Microsoft e Dynamics 365 sono marchi del gruppo di società Microsoft. UAT Studio non è affiliato a Salesforce o Microsoft né approvato da loro.