Implementazione del cloud - Test

Completato

Questa unità è un riepilogo dei passaggi della fase di test di un'implementazione cloud delle app per la finanza e le operazioni.

Distribuzione di un ambiente sandbox

L'ambiente sandbox include tutte le funzionalità principali delle applicazioni Dynamics e in genere contiene dati di esempio o dimostrativi. Occasionalmente l'ambiente sandbox può essere reimpostato sul prodotto base. Alla fine di ogni ciclo, dopo che il responsabile delle decisioni aziendali del cliente approva i requisiti, l'ambiente sandbox viene convertito in ambiente di formazione e la build del ciclo sprint finale viene distribuita nell'ambiente di formazione.

In tal modo gli istruttori possono apprendere le personalizzazioni e iniziare a produrre il materiale di formazione. Gli ambienti sandbox possono essere usati anche per i test delle prestazioni, per garantire che il prodotto soddisfi le esigenze di prestazioni indicate nelle specifiche dei requisiti.

Test e approvazione

Quando un requisito è stato analizzato, progettato e sviluppato, deve essere testato prima che possa essere considerato completato.

Ogni script di test prodotto durante l'attività "Crea script di test" deve essere eseguito e qualsiasi errore deve essere registrato come bug in Azure DevOps (precedentemente conosciuto come Visual Studio Team Services (VSTS)) e discusso tra il consulente e l'esperto di dominio (SME) del cliente per determinare quali modifiche devono eventualmente essere apportate allo sviluppo o agli script di test.

Se sono necessarie modifiche durante questa attività, è necessario effettuare una stima iniziale per l'implementazione delle modifiche. Se questa stima iniziale può essere inclusa nel ciclo sprint giornaliero senza influire su altri risultati finali, le modifiche sono accettate.

Tuttavia, se si prevede che la modifica estenda il tempo di stima originale e influisca sulla consegna di altri requisiti all'interno del ciclo sprint giornaliero, è necessario inviare una richiesta di modifica. La richiesta di modifica deve registrare la modifica richiesta e quindi essere discussa durante una sessione di anteprima tecnica sprint.

Nessuna modifica deve essere incorporata nel ciclo se comporta l'aumento della durata di qualsiasi stima di requisito o stima dettagliata dell'attività. Quando tutti i test del ciclo sprint per il requisito sono stati completati e tutte le modifiche richieste sono state apportate o documentate con una richiesta di modifica, il requisito viene considerato come "Completato" e viene intrapresa la successiva attività del requisito.

Monitoraggio dell'integrità del sistema

In qualsiasi momento è possibile monitorare lo stato di integrità del sistema usando il dashboard Monitoraggio e diagnostica in Lifecycle Services e risolvere eventuali problemi riscontrati nell'ambiente. È inoltre possibile usare la diagnostica di sistema per identificare colli di bottiglia e problemi di prestazioni, insieme a eventuali avvisi o errori dei dati raccolti dagli appositi agenti in Lifecycle Services che estraggono i dati dall'istanza delle app per la finanza e le operazioni.

Individuazione dei bug

Dopo il processo di test è necessario valutare i bug. Sono inclusi i bug di personalizzazioni o i bug che richiedono l'attenzione di Microsoft. Ogni bug deve essere valutato in relazione all'impatto sul progetto.

Ticket di supporto

È possibile generare un ticket di supporto presso Microsoft usando il servizio di supporto in Lifecycle Services. Usare il servizio di supporto per creare incidenti e inviare ticket di supporto al proprio team di sviluppo o a Microsoft.

Download degli aggiornamenti da Microsoft

In qualsiasi momento del ciclo di vita è possibile scaricare gli aggiornamenti rapidi relativi a qualsiasi ambiente dalla pagina Ambiente. È possibile usare lo strumento Aggiorna in Lifecycle Services per aggiornare l'applicazione e i pacchetti binari.

Chiusura dei bug prioritari

Assicurarsi che tutti i bug prioritari siano stati consegnati, testati e chiusi.

Analisi del codice

L'Analisi personalizzazione offre ai clienti delle app per la finanza e le operazioni uno strumento automatizzato per la convalida dei loro file di modello rispetto alle regole delle procedure consigliate per tabelle, classi, moduli ed enumerazioni delle app per la finanza e le operazioni. Genera quindi report che elencano tutti i problemi identificati. Assicurarsi di valutare le personalizzazioni usando l'Analisi personalizzazione e segnalare i bug per i problemi identificati.

Migrazione dei dati

Assicurarsi che la migrazione dei dati venga eseguita e testata dagli utenti aziendali. Questa operazione deve essere eseguita prima del test di accettazione utente.

Test di accettazione utente

Tutti gli scenari aziendali devono essere testati con i dati di produzione nell'ambiente di destinazione. L'approvazione del test di accettazione utente è richiesta dal cliente.

Approvazione di una gold build

È possibile che la propria azienda sia interessata anche ad avere un ambiente gold. L'ambiente gold è usato per eseguire lo staging dei dati per il go live e funge da database di record per l'implementazione. Questo ambiente deve essere mantenuto il più aggiornato possibile in quanto funge da sistema di registrazione durante simulazioni di go live e attività pre-go live. Per applicare una gold build all'ambiente di produzione, approvare la gold build che si intende usare. Una volta creata la gold build, caricarla nella raccolta di risorse di Lifecycle Services e contrassegnarla come gold build. Usare le raccolte di risorse per questa fase di implementazione.

Approvazione dei test delle prestazioni

I test delle prestazioni sono una combinazione di test di integrità del sistema e feedback dell'utente finale per garantire che tutti gli ambienti funzionino come previsto. È inoltre possibile usare la diagnostica di sistema per identificare colli di bottiglia e problemi di prestazioni.