Pianificazione dell'implementazione di Power BI: convalidare il contenuto

Nota

Questo articolo fa parte della serie di articoli sulla pianificazione dell'implementazione di Power BI. Questa serie è incentrata principalmente sull'esperienza Power BI in Microsoft Fabric. Per un'introduzione alla serie, vedere Pianificazione dell'implementazione di Power BI.

Questo articolo consente di convalidare il contenuto come parte della gestione del ciclo di vita del contenuto. È destinato principalmente a:

• Centro di eccellenza (COE) e team BI: team responsabili della supervisione di Power BI nell'organizzazione. Questi team includono decision maker che decidono come gestire il ciclo di vita del contenuto di Power BI. Questi team possono anche includere responsabili delle versioni, che gestiscono il ciclo di vita delle versioni del contenuto e tecnici che creano e gestiscono i componenti necessari per usare e supportare in modo efficace la gestione del ciclo di vita.
• Autori di contenuti e proprietari di contenuti: utenti che creano contenuti che vogliono pubblicare nel portale di Fabric per condividerli con altri utenti. Questi utenti sono responsabili della gestione del ciclo di vita del contenuto di Power BI creato.

La gestione del ciclo di vita è costituita dai processi e dalle procedure usate per gestire il contenuto dalla creazione al ritiro finale. Nella seconda fase della gestione del ciclo di vita si sviluppano contenuti e si gestiscono le modifiche, che implicano decisioni chiave su come sviluppare contenuti e configurare aree di lavoro e sul controllo della versione. Nella terza fase si convalida il contenuto per verificare se è pronto per la distribuzione.

Nota

In genere si esegue l'iterazione delle fasi due e tre nei cicli di sviluppo e convalida successivi.

La convalida del contenuto è fondamentale per garantire la qualità e l'attendibilità delle soluzioni. Per questo motivo, è essenziale testare le modifiche al contenuto prima di distribuirle nell'ambiente di produzione.

L'immagine seguente illustra il ciclo di vita del contenuto di Power BI, evidenziando la fase tre, in cui si convalida il contenuto.

Nota

Per una panoramica della gestione del ciclo di vita dei contenuti, vedere il primo articolo di questa serie.

Questo articolo è incentrato sulle considerazioni e sulle decisioni principali per la convalida del contenuto durante il ciclo di vita. Per altre indicazioni su come convalidare il contenuto, vedere:

• Eseguire la migrazione a Power BI: convalidare il contenuto: questo articolo descrive le considerazioni e le decisioni principali per la convalida quando si esegue la migrazione a Power BI da altre tecnologie.
• Pianificazione della soluzione BI: convalidare il contenuto: questo articolo descrive come pianificare cicli di sviluppo e convalida iterativi durante la pianificazione della soluzione Power BI o Fabric.

La convalida del contenuto comporta decisioni o azioni specifiche per garantire che il contenuto venga eseguito come previsto.

Quando si convalida il contenuto, si valutano diversi aspetti della soluzione.

• Funzionalità: ovvero se gli elementi e le funzionalità che costituiscono la soluzione sono funzionali. Un esempio di test delle funzionalità consiste nel valutare se un modello semantico possa completare un aggiornamento pianificato.
• Accuratezza dei dati: ovvero se le cifre e i risultati visualizzati sono completi e in linea con le aspettative aziendali. Un esempio di test dell'accuratezza dei dati consiste nel valutare se un valore in un report è in linea con una linea di base nota.
• Prestazioni: ovvero se le query producono un impatto minimo sulle risorse utente disponibili o sui tempi di attesa degli utenti. Un esempio di test delle prestazioni consiste nel valutare se un flusso di dati viene aggiornato in modo affidabile senza raggiungere il timeout o riscontrare durate di aggiornamento prolungate.
• Sicurezza: ovvero se agli utenti non autorizzati venga limitata la visualizzazione o l'accesso alle informazioni oppure all'intera soluzione. Un esempio di test della sicurezza consiste nella rappresentazione di un utente o di un ruolo durante la convalida della sicurezza a livello di riga.
• Efficacia: ovvero se la soluzione risolve il problema o il processo aziendale pertinente e se supporta sufficientemente gli obiettivi aziendali previsti. Un esempio di test di efficacia consiste nella raccolta di feedback degli utenti quando si eseguono test di accettazione utente.
• Accessibilità: ovvero se la soluzione soddisfa gli standard di accessibilità noti in modo che sia utilizzabile dal maggior numero possibile di persone. Un esempio di test di accessibilità consiste nel verificare che il report soddisfi l'elenco di controllo per l'accessibilità dei report Microsoft.

Per convalidare il contenuto, eseguire diversi tipi di test. Le sezioni seguenti descrivono le considerazioni chiave per le decisioni relative al modo in cui gli autori di contenuti e i consumer di contenuti eseguono test.

Nota

Molti team usano metodologie di test provenienti dallo sviluppo software, ad esempio test di unità, test di integrazione e smoke test. Esistono molti approcci ugualmente validi per il test e la convalida del contenuto. La cosa più importante è che il contenuto venga testato usando un approccio ottimale a seconda delle proprie esigenze e della modalità di lavoro del team.

Decidere in che modo gli autori devono convalidare il contenuto

Gli autori di contenuti devono convalidare le proprie modifiche al contenuto per garantire la qualità e le funzionalità delle modifiche. I test vengono in genere eseguiti nell'area di lavoro di sviluppo, che contiene la versione di lavoro più recente di una soluzione. Gli autori di contenuti testano le proprie modifiche prima che il contenuto venga distribuito in un'area di lavoro di test per la convalida dell'utente.

Nota

È essenziale che gli autori di contenuti convalidino il proprio contenuto prima che venga reso disponibile agli utenti. Se la soluzione fornita agli utenti per il test presenta problemi evidenti, l'attendibilità della soluzione viene erosa. Anche in fase di test, gli utenti si aspettano di vedere una rappresentazione ragionevole del prodotto finale. Inoltre, una soluzione funzionale consente agli utenti di concentrarsi sull'identificazione dei problemi correlati all'area aziendale.

Esistono due modi per consentire agli autori di contenuti di convalidare il contenuto.

• Test manuali: i test manuali implicano la convalida manuale del contenuto, tramite una valutazione soggettiva o un confronto con alcuni criteri di test oggettivi. I test manuali sono facili da eseguire, ma sono soggetti a errori umani o distorsioni. Inoltre, quando il contenuto raggiunge una determinata scala, i test manuali possono diventare laboriosi da eseguire correttamente. È possibile eseguire test manuali in due modi.
  • Revisione indipendente, che implica il test del proprio contenuto, ad esempio modelli semantici e report.
  • Revisione paritaria, che implica una valutazione soggettiva del contenuto per valutare criticamente la soluzione e fornire suggerimenti per migliorarla.
• Test automatizzati: i test automatizzati consistono in un test preparato in anticipo che viene valutato automaticamente senza intervento umano. In genere, i test automatizzati controllano parti del codice della soluzione confrontandole con benchmark o linee di base specifiche. I test automatizzati sono più difficili da eseguire e richiedono tempo e impegno per essere configurati. Tuttavia, i test automatizzati sono essenziali negli scenari aziendali per garantire la qualità e l'attendibilità delle implementazioni più grandi e delle soluzioni critiche per l'azienda.

Le sezioni seguenti descrivono diversi modi in cui gli autori di contenuti possono eseguire test manuali, test automatizzati e revisioni paritarie.

Eseguire test manuali

È consigliabile eseguire test manuali sul contenuto creato. Questi test devono garantire che le modifiche funzionino come previsto e raggiungano gli standard di qualità desiderati. In genere, il test manuale implica l'uso e la valutazione soggettiva del contenuto o delle modifiche di contenuto specifiche, nonché la descrizione e la documentazione dei risultati.

Di seguito sono riportate alcune considerazioni per testare il proprio contenuto.

• Decidere e documentare in anticipo le condizioni di test e i criteri di esito positivo.
• Eseguire i test e documentare i risultati con accuratezza. Assicurarsi, ad ogni modo, di evitare test superflui, in modo che le procedure di test non rallentino lo sviluppo.
• Creare un set standard di test per ogni tipo di elemento per migliorare la ripetibilità.
• Documentare i risultati e le conclusioni dei test.
• Testare più volte per garantire che i risultati dei test riflettano meglio la realtà e non la probabilità casuale.
• Usare condizioni di test rappresentative dell'ambiente di produzione.

Le sezioni seguenti descrivono altre considerazioni chiave per i test manuali.

Testare manualmente i modelli semantici

I modelli semantici sono una parte importante di una soluzione in Fabric e Power BI perché sono un'origine upstream per report, dashboard e altri strumenti client e carichi di lavoro di Fabric. Di conseguenza, è importante convalidare i modelli semantici prima della distribuzione.

Rispondere a domande come le seguenti per convalidare il modello semantico.

• Le tabelle contengono valori mancanti, duplicati o non corretti imprevisti?
• Le misure DAX restituiscono i risultati previsti senza tempi di query lunghi?
• L'aggiornamento pianificato viene completato correttamente senza tempi di aggiornamento lunghi?
• Si osservano risultati (vuoti) in oggetti visivi, filtri o risultati di query causati da violazioni di integrità referenziale?
• La sicurezza dei dati, ad esempio la sicurezza a livello di riga o la protezione a livello di oggetto, impedisce sufficientemente agli utenti non autorizzati di accedere al modello o ai relativi dati?
• Gli oggetti modello, ad esempio le misure DAX o le colonne della tabella, sono organizzati in cartelle di visualizzazione?

È possibile usare diversi strumenti e approcci per convalidare i modelli semantici.

• Power BI Desktop: Power BI Desktop consente di convalidare diversi aspetti dei modelli semantici usando varie funzionalità. Esempi di funzionalità di Power BI Desktop che facilitano il test dei modelli semantici includono:
  • Area di disegno visiva: per testare la funzionalità del modello e l'accuratezza con oggetti visivi di trascinamento della selezione.
  • Visualizzazione query DAX: per testare l'accuratezza del modello e il codice DAX con query DAX che è possibile salvare e riutilizzare in un secondo momento.
  • Diagnostica query: per testare le prestazioni di aggiornamento ottenendo informazioni di diagnostica sulla valutazione delle query in Power Query.
• Fabric: le funzionalità e gli elementi nel portale di Fabric consentono di convalidare gli aspetti del modello semantico dopo la distribuzione in un'area di lavoro.
  • Sicurezza: per testare la sicurezza del modello rappresentando ruoli o utenti di sicurezza.
  • Notebook: per testare la funzionalità e l'accuratezza del modello usando il collegamento semantico.
  • Hub di monitoraggio: per testare e monitorare l'aggiornamento dei dati dei modelli semantici e di altri elementi di dati di Fabric.
• Strumenti di terze parti: gli strumenti di terze parti consentono di convalidare altri aspetti del modello semantico, sia fornendo maggiori dettagli sia con altre funzionalità che facilitano la convalida. Esempi di strumenti di terze parti che facilitano il test dei modelli semantici includono:
  • DAX Studio: per testare e ottimizzare le prestazioni del codice DAX ricevendo suddivisioni dettagliate dei tempi delle query DAX e dei piani di query.
  • Editor tabulare: per testare ed eseguire il debug dell'accuratezza del codice DAX ricevendo suddivisioni dettagliate relative alla modalità di valutazione delle query DAX e al contesto di valutazione attivo.

Suggerimento

È possibile usare la diagnostica delle query per convalidare e ottimizzare manualmente le prestazioni di Power Query da altri elementi che lo usano, ad esempio i flussi di dati.

Inoltre, è possibile usare la visualizzazione query DAX e gli strumenti di terze parti come DAX Studio per convalidare e ottimizzare le query DAX per report impaginati e scorecard.

Testare manualmente i report

I report sono un modo comune per consentire agli utenti di interagire con i dati. Molti utenti si basano sui report per prendere decisioni e intraprendere azioni per compiere progressi verso i propri obiettivi aziendali. Di conseguenza, è importante convalidare i report prima della distribuzione.

Rispondere a domande come le seguenti per convalidare i report.

• I report soddisfano i requisiti aziendali documentati?
• Vengono usati i tipi di oggetti visivi corretti per rispondere alla giusta domanda?
• Le pagine del report sono chiare e concise senza colori travolgenti o troppi oggetti visivi?
• Il report funziona come previsto quando si filtra un sottoinsieme di dati ristretto?
• Il report consente l'esportazione in Excel e, in tal caso, consente di recuperare i dati riepilogati o i dati sottostanti?
• È possibile usare il report per il drill-through tra report o la personalizzazione degli oggetti visivi?

È possibile usare diversi strumenti e approcci per convalidare i report.

• Power BI Desktop: Power BI Desktop consente di convalidare diversi aspetti dei report usando varie funzionalità. Esempi di funzionalità di Power BI Desktop che facilitano il test dei report includono:
  • Area di disegno visiva: per testare la funzionalità del report usando filtri dei dati, filtri e altri elementi interattivi.
  • Analizzatore prestazioni: per testare le prestazioni del report misurando il rendering visivo e i tempi di query DAX. È possibile copiare query DAX visive dall'analizzatore delle prestazioni per usarle in altri strumenti e salvare i risultati delle prestazioni per la documentazione.
  • Simulazioni limite di query: per testare le prestazioni del report simulando i limiti di memoria nella capacità in cui verrà distribuita.
• Fabric: le funzionalità e gli elementi nel portale di Fabric consentono di convalidare gli aspetti del report dopo la distribuzione in un'area di lavoro.
  • Aggiornare l'app: per testare la funzionalità e la sicurezza dei report durante la distribuzione di report nelle app Power BI e durante l'impostazione di destinatari di app diversi per determinare chi può visualizzare quale contenuto. Quando si usano i gruppi di destinatari delle app, si possono visualizzare in anteprima i report a cui avranno accesso e si può testare l'esperienza dell'app personalmente.
  • Visualizzazione di lettura nell'area di lavoro o nell'app: per testare la funzionalità e l'accuratezza del report usandolo nello stesso ambiente di un utente.

Nota

È possibile sviluppare e convalidare i dashboard solo nel portale di Fabric.

Importante

È essenziale testare i report in Power BI Desktop e poi nel portale di Fabric dopo la distribuzione. Il rendering visivo può comportarsi in modo diverso nel computer locale rispetto ai report in un'area di lavoro di Fabric. Tenere inoltre presente che l'esperienza utente dell'uso di un report da un'area di lavoro o da un'app differisce in modo significativo rispetto all'uso di un report in Power BI Desktop.

Testare manualmente eseguendo una revisione paritaria

Un altro modo per convalidare manualmente il contenuto consiste nell'eseguire una revisione paritaria. In una revisione paritaria, l'autore del contenuto fornisce la soluzione o parte della soluzione a un collega affinché la valuti. Lo scopo di una revisione paritaria è migliorare una soluzione usando l'esperienza collettiva e la competenza di più creatori di contenuti. È possibile eseguire una revisione paritaria sia durante che dopo test manuali e automatizzati.

Nota

La revisione paritaria è un approccio standard usato in molti settori. Questo approccio è comunemente noto per migliorare la qualità dei contenuti, dei prodotti e dei processi.

Suggerimento

Se si è l'unico creatore di contenuti per una soluzione, è consigliabile trovare un altro creatore di contenuti in un team diverso affinché revisioni la soluzione, offrendo in cambio di fare lo stesso.

Esistono diversi modi per eseguire una revisione paritaria.

• Revisione funzionale: una revisione funzionale è incentrata su funzionalità, processi o requisiti aziendali che la soluzione deve soddisfare. In una revisione funzionale, i revisori usano la soluzione come se fossero un utente finale. Documentano eventuali difetti o problemi che trovano, insieme a qualsiasi critica soggettiva per migliorare l'implementazione.
• Revisione tecnica: una revisione tecnica è incentrata sugli aspetti tecnici della soluzione, ad esempio la modellazione dei dati, il codice o la progettazione. In una revisione tecnica, i revisori valutano il modo in cui sono state implementate determinate funzionalità o modifiche e suggeriscono approcci alternativi o evidenziano potenziali difetti o rischi dell'approccio corrente.
• Richiesta pull: quando si esegue il controllo del codice sorgente, si crea una richiesta pull per unire le modifiche alla versione più recente di una soluzione. Un proprietario tecnico esamina le modifiche proposte e valuta il codice sorgente. Questo tipo di revisione è utile per garantire che il codice rispetti le convenzioni standard, ad esempio la formattazione di codice DAX o M, o l'identificazione di anti-pattern o codice potenzialmente problematico.

Suggerimento

È consigliabile eseguire una revisione paritaria e un'approvazione formali prima che le modifiche al contenuto possano passare ai test di accettazione dell'utente. Questo perché un contenuto di scarsa qualità può compromettere la fiducia nelle soluzioni dati, anche durante i test. Inoltre, la revisione paritaria può anche trarre vantaggi dalla collaborazione e dalla condivisione delle conoscenze tra i membri del team.

Dopo aver completato un ciclo di revisione paritaria, è necessario documentare e incorporare eventuali modifiche consigliate. Se necessario, è bene inviare di nuovo le modifiche per l'approvazione prima di passare al test utente. In genere, sono necessarie più iterazioni di revisione paritaria solo quando sono presenti molte modifiche o alcune modifiche complesse da testare.

Automatizzare i test

Gli autori di contenuti possono automatizzare i test in modo che vengano eseguiti automaticamente prima della distribuzione. I test automatizzati in genere comportano condizioni di test preparate in anticipo eseguite e orchestrate a livello di codice in risposta a determinate azioni, ad esempio il salvataggio del contenuto o l'invio di una richiesta pull. I risultati dei test automatizzati vengono archiviati automaticamente per la consultazione e la documentazione future.

Lo scopo di un test automatizzato è ridurre il tempo e il lavoro necessario per convalidare le modifiche al contenuto, migliorando al tempo stesso la coerenza dei test e l'affidabilità dei risultati. Quando il contenuto non supera un test automatizzato, ne viene in genere impedita la distribuzione fino a quando i problemi non vengono risolti dall'autore del contenuto.

Un test automatizzato efficace è una parte fondamentale dell'implementazione di DataOps. DataOps consente ai team di automatizzare e ridimensionare i processi adottando procedure che migliorano e accelerano la distribuzione di dati e analisi.

Importante

Per automatizzare in modo efficace i test, è necessario creare test ben progettati. La creazione di tali test può richiedere tempo e impegno significativi. Se le condizioni di test e le aspettative non sono definite in modo corretto, i test automatizzati non saranno in grado di convalidare gli aspetti corretti del contenuto e si riceveranno pochi vantaggi dall'automazione di questi test.

Suggerimento

I test automatizzati sono particolarmente utili quando si integrano con la distribuzione della soluzione negli scenari di pubblicazione di contenuti aziendali. Ad esempio, è possibile automatizzare i test usando Azure Pipelines come parte di una pipeline di convalida, che garantisce che il contenuto sia pronto per la distribuzione. Per altre informazioni, vedere Fase 4: Distribuire il contenuto.

Le sezioni seguenti descrivono le considerazioni principali per testare automaticamente i modelli semantici e i report di Power BI.

Automatizzare i test dei modelli semantici

È possibile eseguire test automatizzati dei modelli semantici, anche se in genere richiedono una configurazione personalizzata con strumenti e framework di terze parti.

È possibile usare diversi strumenti e approcci per automatizzare il test dei modelli semantici.

• Best Practice Analyzer (BPA): Best Practice Analyzer consente di specificare le regole che è possibile usare per valutare un modello semantico. È possibile eseguire il BPA usando Tabular Editor, che identificherà eventuali violazioni delle regole in un modello semantico. È possibile automatizzare i controlli per le violazioni delle regole BPA usando l'interfaccia della riga di comando di Tabular Editor insieme ad Azure DevOps o come parte di un altro processo pianificato.
• Notebook di Fabric e collegamento semantico: i notebook di Fabric consentono di usare il collegamento semantico per interagire a livello di codice con i modelli semantici. È possibile usare i notebook per eseguire framework come Great Expectations (GX) per convalidare i dati. Inoltre, è possibile valutare misure e query DAX, quindi testare i risultati a confronto con le linee di base note.
• Power Automate: Power Automate consente di eseguire query su modelli semantici ed esportare report usando le API REST di Power BI. È possibile controllare i risultati della query confrontandoli con le linee di base note e quindi eseguire azioni downstream come l'attivazione di avvisi ai proprietari del contenuto.

Suggerimento

Valutare la possibilità di combinare test automatizzati e orchestrazione dei modelli semantici. Ad esempio, è possibile eseguire test automatizzati su un'origine dati e un modello semantico prima di un aggiornamento usando i notebook o Power Automate. Se i test hanno esito negativo, è possibile impedire l'aggiornamento; ciò può anche impedire errori di aggiornamento o l'inserimento di dati non corretti nei report aziendali.

Automatizzare i test dei report

Sono disponibili opzioni limitate per automatizzare i test dei report. Queste opzioni si basano su strumenti esterni o soluzioni della community per convalidare automaticamente gli oggetti visivi o le proprietà del report, ad esempio la convalida dei metadati del report o la simulazione delle interazioni utente con i report.

È possibile usare diversi strumenti e approcci per automatizzare il test dei report.

• Analizzatori delle procedure consigliate per i report: sono disponibili vari strumenti di terze parti che supportano funzionalità simili a Best Practice Analyzer per automatizzare il rilevamento dei problemi nei report esaminando la definizione del report. Due strumenti che supportano questa funzionalità sono PBI Explorer e PBI Inspector.
• Power Automate Desktop: strumenti di automazione interfaccia utente come Selenium per Python o Power Automate Desktop consentono di simulare le interazioni con il mouse degli utenti con i report. Definendo un flusso utente, è possibile testare la navigazione e le interazioni. Questi test vengono superati quando il flusso può essere completato, mentre hanno esito negativo quando rilevano determinate parole o immagini sullo schermo (ad esempio un messaggio di errore o un oggetto visivo vuoto).

Decidere in che modo gli utenti devono convalidare il contenuto

Una volta superato il test manuale, i test automatizzati e la revisione paritaria, il contenuto può passare ai test degli utenti. Quando gli utenti testano il contenuto, forniscono un feedback soggettivo sulla capacità del contenuto di soddisfare i requisiti aziendali e di funzionare secondo le loro aspettative, nonché sulla restituzione di risultati accurati.

La convalida utente viene in genere eseguita in un'area di lavoro di test. Quando si configura un'area di lavoro di test, tenere conto delle considerazioni seguenti.

• Creare un'app di test: se si intende distribuire il contenuto usando un'app Power BI, configurare un'app di test in cui gli utenti del test possano convalidare il contenuto. L'app di test deve essere identica all'app che verrà configurata nell'ambiente di produzione. Nella struttura dell'app di test è consigliabile includere i collegamenti a documentazione, training e moduli di feedback.
• Effettuare il provisioning dell'accesso: identificare un subset di utenti della community che convalideranno la soluzione. Contattare questi utenti e stabilire un accordo su quando e perché devono convalidare il contenuto. Assicurarsi quindi di fornire loro l'accesso al contenuto e aggiungerli ai ruoli di sicurezza appropriati. Condividere i collegamenti all'app di test o al contenuto con gli utenti in modo che possano iniziare a eseguire il test.
• Configurare l'aggiornamento pianificato: la convalida utente in genere si estende su un periodo più lungo. È consigliabile configurare un aggiornamento pianificato dei dati nell'area di lavoro di test in modo che gli utenti eseguano test con i dati più recenti.

Importante

Quando si distribuisce il contenuto in un'area di lavoro di test, è necessario aggiornare manualmente l'app affinché le modifiche ai report e ai dashboard siano visibili agli utenti.

Nota

Non è possibile distribuire o copiare app da un'area di lavoro a un'altra. Tutte le modifiche apportate a un'app devono essere apportate manualmente nella configurazione per tale area di lavoro.

Prima di iniziare la convalida dell'utente, è necessario eseguire le operazioni di preparazione necessarie.

• Stabilire quando dovrà essere eseguita la convalida dell'utente.
• Specificare se la convalida dell'utente è limitata a un periodo specifico o se fa parte di un processo iterativo.
• Creare un metodo per raccogliere feedback, ad esempio usando Microsoft Forms.
• Comunicare agli utenti coinvolti nella convalida la pianificazione e le aspettative.
• Organizzare un inizio per la convalida degli utenti per guidare gli utenti e gestire le aspettative.
• Eseguire corsi di formazione per gli utenti per illustrare il processo di convalida e feedback.

Ecco alcuni modi diversi per facilitare la convalida del contenuto da parte dell'utente.

• Test di osservazione: i test di osservazione sono brevi sessioni in cui i creatori di contenuti guardano uno o più utenti usare il contenuto senza indicazioni o istruzioni. In queste sessioni, gli autori di contenuti usano le proprie osservazioni per identificare potenziali difetti, problemi o miglioramenti alla soluzione. Questi test possono essere utili perché richiedono poco tempo e sforzo per essere organizzati e possono essere limitati a funzionalità o parti specifiche di una soluzione. I test di osservazione sono più utili per ottenere un feedback anticipato su una progettazione o un approccio, ad esempio con un modello di verifica (PoC).
• Test di gruppo mirato: i test di gruppo mirati sono sessioni limitate organizzate con un piccolo gruppo di utenti che esaminano insieme il contenuto. Questi gruppi mirati sono formati da stakeholder chiave ed esperti in materia che possono fornire il miglior feedback su determinate funzionalità o caratteristiche. I test di gruppo mirati possono svolgersi in più sessioni interattive. I test di gruppo mirati richiedono più tempo e impegno rispetto ai test di osservazione, ma possono fornire feedback più dettagliati su una soluzione.
• Test di accettazione utente: il test di accettazione utente è un processo formale in cui un gruppo più ampio di persone della community utenti convalida e fornisce feedback asincroni su una soluzione. Il test di accettazione utente richiede più tempo e impegno per essere organizzato, ma è il modo più accurato per eseguire test degli utenti. Dopo che gli utenti di test accettano la soluzione e i problemi suggeriti vengono risolti, il contenuto può essere distribuito nell'area di lavoro di produzione.

Dopo aver deciso come convalidare il contenuto, è possibile pianificare come distribuirlo all'interno e tra le aree di lavoro.

Elenco di controllo - Quando si pianifica come convalidare il contenuto, le decisioni chiave e le azioni includono:

• Progettare e documentare le condizioni di test: descrivere i test che verranno eseguiti, cosa testano e come si svolgeranno.
• Stabilire un processo di revisione paritaria: descrivere chi altro convaliderà il contenuto a parte se stessi.
• Stabilire un approccio al test manuale: decidere quali strumenti e funzionalità verranno usati per convalidare il contenuto creato.
• Stabilire se usare test automatizzati: valutare se la scalabilità e l'ambito del contenuto giustificano la configurazione di test automatizzati. In tal caso, assicurarsi di pianificare il tempo e le risorse necessarie per progettare e implementare questi test in modo che convalidino quanto previsto.
• Distribuire il contenuto dall'area di lavoro di sviluppo all'area di lavoro di test: distribuire le modifiche dall'area di lavoro di sviluppo all'area di lavoro di test in modo che le modifiche siano visibili agli utenti. Assicurarsi di aver eseguito le attività di post-distribuzione necessarie nell'area di lavoro di test, ad esempio la configurazione e l'aggiornamento di un'app di test.
• Stabilire un approccio ai test utente: decidere come gli utenti convalideranno il contenuto.
• Identificare gli utenti di test: identificare chi tra la community utenti convaliderà il contenuto. Raggiungere un accordo con questi utenti sull'entità del loro coinvolgimento e sulle loro aspettative.
• Raccogliere i feedback degli utenti: configurare strumenti e processi per raccogliere automaticamente i feedback. Ad esempio, è possibile usare Tasks e Planner in Microsoft Teams o Microsoft Forms.
• Documentare i risultati di test: documentare i risultati di tutta la convalida del contenuto e le eventuali modifiche apportate sulla base dei risultati del test. Assicurarsi che questa documentazione sia facilmente reperibile.
• Pianificare la distribuzione nell'ambiente di produzione: al termine dei test utente, prepararsi per la distribuzione del contenuto dall'area di lavoro di test all'area di lavoro di produzione.

Contenuto correlato

Nell'articolo successivo di questa serie viene illustrato come distribuire il contenuto come parte della gestione del ciclo di vita del contenuto.