Introduzione
Il lavoro di un Architetto di soluzioni non finisce con la progettazione del sistema. Infatti, deve assicurarsi che il sistema venga distribuito e usato da utenti reali.
Il ruolo dell'Architetto di soluzioni nei test e nella pubblicazione
In genere, l'Architetto di soluzioni è una delle persone più informate sul funzionamento della soluzione e, pertanto, più adatte a guidare i test condotti dal team di test.
L'Architetto di soluzioni ha un ruolo chiave nell'esecuzione di test e dovrebbe:
- Restare coinvolto fino alla fine del test per garantirne il successo.
- Aiutare a formare il team di test sull'architettura della soluzione per garantire che testi adeguatamente tutti i componenti e le integrazioni.
- Valutare i problemi complessi che sorgono durante i test, le prove e dopo la pubblicazione.
- Collaborare con il team per la pubblicazione alla pianificazione e all'implementazione della relativa strategia.
Panoramica dei test
È importante condurre test adeguati per garantire il successo del progetto.
Nota
Le operazioni di test devono essere continue, dal primo componente creato fino alla pubblicazione. Non possono essere gestite come grandi iniziative occasionali.
L'esecuzione di test va oltre il processo di mapping dei requisiti alle funzionalità. Sebbene sia importante creare e implementare questi tipi di test, devono essere testati anche altri aspetti di una soluzione. Il processo è analogo e prescinde dalla metrica specifica che viene testata.
Il processo di test include i seguenti passaggi:
Pianificazione: rivedere la strategia di test complessiva, sviluppare il piano di test ed eseguire l'analisi necessaria per le metriche di riferimento. Identificare gli scenari aziendali chiave inclusi ed esclusi dall'ambito. Documentare i requisiti, se questo passaggio non è già stato completato.
Preparazione: configurare gli ambienti necessari per i test delle prestazioni, i test di accettazione utente e così via. Rivedere i dati ricevuti per la migrazione, prima e dopo il test di migrazione. Convalidare i requisiti generali di sistema, quindi sviluppare gli script necessari.
Esecuzione: eseguire gli script di test, analizzare i risultati, identificare potenziali colli di bottiglia e, quindi, esaminare errori e comportamenti.
Report: preparare una valutazione dettagliata del piano di creazione di report, dei risultati e del piano di azione.
Tipi di test
L'Architetto di soluzioni dovrebbe partecipare alla discussione relativa alla quantità e al tipo di test richiesti per un progetto.
I tipi di test più comuni in Microsoft Power Platform includono:
Unit test: eseguiti dal creatore dell'app, dall'analista aziendale, dal consulente funzionale o dallo sviluppatore.
Test funzionali: verificano che l'implementazione soddisfi i requisiti.
Test di accettazione: eseguiti dagli utenti per fornire un'approvazione formale.
Test di regressione: verificano la regressione delle funzioni invariate e, in genere, vengono eseguiti a ogni aggiornamento del sistema.
Test di integrazione: hanno l'obiettivo di verificare che tutti i sistemi integrati funzionino senza conflitti. Il test di integrazione controllano che tutti i componenti funzionino correttamente insieme, inclusi i servizi integrati e i dati provenienti da altre fonti.
Test delle prestazioni: questi test vengono condotti durante picchi previsti di carico e di volume di transazioni e sono generalmente automatizzati ed eseguiti prima della pubblicazione.
Test di migrazione: provano a eseguire la migrazione dei dati per garantirne la qualità. Questi test vengono eseguiti avvalendosi della costante consulenza di esperti di dominio che conoscono i dati del cliente. Questi esperti dovrebbero comprendere la transizione e la trasformazione dei dati e possono confermare che i dati sottoposti a migrazione sono validi nel contesto appropriato.
Test di ripristino di emergenza: un piano per il ripristino di emergenza è inutile se non funziona.
Test per la pubblicazione: prove della soluzione finale e processo di pubblicazione. Questi test vengono generalmente eseguiti prima della pubblicazione.
Non è necessario condurre tutti i tipi di test. La scelta dipende dalle dimensioni e dall'ambito del progetto.
Unit test
Uno unit test può essere usato per verificare se una funzione o una funzionalità specifica dell'app funziona correttamente. In genere, gli unit test vengono condotti dai creatori di app e dagli sviluppatori. Ogni membro del team dovrebbe controllare il proprio lavoro prima della consegna.
Gli unit test sono consigliati, ma non obbligatori. All'inizio, o se la quantità di codice nella soluzione è relativamente piccola, si potrebbe avere la sensazione di star dedicando più tempo alla scrittura dei test che alla creazione della funzionalità inclusa nella soluzione. I vantaggi degli unit test iniziano a emergere quando la soluzione diventa più grande e complessa, in particolare con lo sviluppo lato server, che trae vantaggi significativi dall'uso del debug locale basato su dati fittizi con un framework di test.
È possibile eseguire test manuali con tutte le app, le regole di business e i plug-in. Alcuni test possono essere automatizzati con Microsoft Power Apps Studio e Visual Studio. Un framework di unit test molto usato per lo sviluppo lato server è Fake Xrm Easy.
Spetta all'Architetto di soluzioni decidere gli strumenti da usare per gli unit test e il livello di automazione da applicare.
Test di integrazione
L'Architetto di soluzioni deve aiutare il team di test a capire come testare i componenti integrati.
Un vantaggio di Microsoft Power Platform è la sua notevole capacità di integrazione. L'integrazione è uno degli aspetti più importanti dell'implementazione dei processi aziendali perché ne garantisce il corretto funzionamento e il forte impatto sull'adozione complessiva.
L'Architetto di soluzioni e il cliente devono esaminare gli scenari di test che prevedono integrazioni con altre applicazioni line-of-business per assicurare che vengano creati scenari di test end-to-end. Questo esame richiederà probabilmente che il cliente pianifichi la preparazione di ambienti di test per le altre applicazioni.
È probabile che ciascuna integrazione abbia uno specifico approccio per i test, che è necessario definire. Il team di test dovrebbe essere coinvolto già nelle fasi iniziali per definire come condurre i test su ogni scenario di integrazione. I team devono garantire la configurazione delle integrazioni necessarie per supportare i test.
Un aspetto chiave dei test di integrazione riguarda l'attenzione rivolta ai dati che si muovono dentro e fuori dall'integrazione. Gran parte della discussione nella sezione dei test di convalida dei dati può essere applicata anche ai dati usati nelle integrazioni.
Poiché i test di integrazione possono coinvolgere altri sistemi, è necessario assicurarsi che gli ambienti di test vengano usati per tutti i componenti. È necessario evitare che i test di integrazione comunichino con un sistema live, rischiando di modificare accidentalmente i dati di produzione. A volte, gli scenari di test determineranno le opzioni di configurazione nell'integrazione dell'applicazione per renderla testabile. La possibilità di disattivare le integrazioni consente di eseguire i test senza richiamare l'integrazione.
Il processo di creazione delle integrazioni ora è più semplice, quindi più accessibile a un numero maggiore di persone nei team di progetto. Le integrazioni spesso possono essere nascoste nelle applicazioni canvas di Power Apps o nei flussi di Microsoft Power Automate. Accade spesso che queste integrazioni nascoste passino inosservate perché l'applicazione usa un connettore di superficie di un'altra origine. Il piano dovrebbe considerare queste integrazioni come qualsiasi altra integrazione e quindi testarle di conseguenza.
test di accettazione utente
I test di accettazione utente (UAT) vengono eseguiti dagli utenti per fornire un'approvazione formale e testare l'usabilità del sistema. Un test di accettazione in genere viene eseguito come controllo finale prima dell'implementazione della funzionalità. L'obiettivo di questo test è garantire che quanto prodotto dei creatori corrisponda ai requisiti inizialmente indicati dall'utente.
Suggerimenti per ottenere buoni risultati dai test UAT:
- Condurre il test con utenti reali.
- Scegliere utenti con diversi livelli di competenza IT. Ciò consente di ottenere commenti eterogenei.
- Non dare istruzioni all'utente. Lasciarlo libero per vedere se riesce a capire l'app in modo intuitivo.
- Osservare in che modo gli utenti navigano nell'app senza assistenza, quindi individuare gli aspetti della progettazione che possono essere migliorati.
- Quando l'utente è bloccato su una schermata, chiedere di spiegare cosa si aspetta.
- Provare a usare dispositivi diversi per verificare che i test case abbiano comportamenti simili.
- Idealmente, testare l'app nell'ambiente o nella posizione effettiva dell'utente, se l'app usa funzionalità offline.
- Chiedere agli utenti di provare a "mettere in difficoltà" l'app, ad esempio inserendo caratteri insoliti nelle colonne di testo.
- Gli utenti tenderanno a testare il "percorso senza ostacoli", ovvero il percorso che un utente segue quando non incontra problemi. Chiedere ai clienti di testare anche scenari come l'annullamento di una nota spese invece dell'invio o il rifiuto di una nota spese invece dell'approvazione.
Gli utenti potrebbero non avere familiarità con il software di test. Comunicare agli utenti il tipo di commento desiderato. Spesso è utile fornire un modello per i bug per assicurarsi che i tester descrivano esattamente cosa stavano facendo, cosa è successo, cosa si aspettavano che accadesse e le informazioni pertinenti al loro ambiente di test, ad esempio il tipo di dispositivo e il browser.
L'Architetto di soluzioni dovrà aiutare a valutare i problemi sollevati dagli utenti durante il test.
Test di sicurezza
I test di sicurezza sono importanti per garantire la sicurezza dell'applicazione e l'allineamento ai requisiti normativi. Questi test dovrebbero includere una valutazione delle vulnerabilità per verificare che l'applicazione sia sicura. Dovrebbero includere anche la verifica effettuata dal contesto di sicurezza di diversi tipi di utenti per garantire che sia disponibile un livello appropriato di dati e funzionalità.
I test di sicurezza dovrebbero anche esaminare il modello di sicurezza all'interno dell'applicazione per l'accesso ai dati e alle funzionalità. I test dovrebbero includere scenari con più utenti con ruoli e caratteristiche di accesso diversi per verificare che il modello di sicurezza regga. I test del modello di sicurezza dovrebbero controllare che non si verifichi una condivisione eccessiva o insufficiente. Un modo per gestire i test del modello di sicurezza consiste nel creare un account utente di test dedicato per ogni set di ruoli principale.
L'Architetto di soluzioni dovrebbe aiutare a definire il livello dei test di sicurezza da eseguire.