Condividi tramite


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 di Power BI all'interno di 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: i 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 contenuto e configurare aree di lavoro e controllo della versione. Nella terza fase si convalida il contenuto per verificare se è pronto per la distribuzione.

Nota

In genere si scorre le 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.

Il diagramma mostra il ciclo di vita del contenuto di Power BI. La fase 3, che riguarda la convalida del contenuto, è evidenziata.

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:

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à: indica se gli elementi e le funzionalità che costituiscono la soluzione sono funzionali. Un esempio di funzionalità di test è se un modello semantico può completare un aggiornamento pianificato.
  • Accuratezza dei dati: indica se le cifre e i risultati visualizzati sono completi e allineati alle aspettative aziendali. Un esempio di test dell'accuratezza dei dati è se un valore in un report è allineato a una linea di base nota.
  • Prestazioni: indica se le query producono un impatto minimo sulle risorse utente disponibili o sui tempi di attesa degli utenti. Un esempio di prestazioni di test è se un flusso di dati viene aggiornato in modo affidabile senza raggiungere il timeout o riscontrare durate di aggiornamento prolungate.
  • Sicurezza: indipendentemente dal fatto che gli utenti non autorizzati non siano autorizzati a visualizzare o accedere alle informazioni o all'intera soluzione. Un esempio di test della sicurezza è la rappresentazione di un utente o di un ruolo durante la convalida della sicurezza a livello di riga.
  • Efficacia: indica se la soluzione risolve il problema o il processo aziendale pertinente e supporta sufficientemente gli obiettivi aziendali previsti. Un esempio di efficacia dei test è la raccolta di commenti e suggerimenti degli utenti quando si eseguono test di accettazione utente (UAT).
  • Accessibilità: indica 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 unit test, test di integrazione e smoke test. Esistono molti approcci ugualmente validi per il test e la convalida del contenuto. L'aspetto più importante è che si testa il contenuto usando un approccio ottimale per le proprie esigenze e il modo in cui funziona il 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 convalidano il proprio contenuto prima che venga reso disponibile agli utenti. Se viene fornita una soluzione per testare gli utenti con problemi evidenti, l'attendibilità nella soluzione viene erosa. Anche quando si esegue il 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 confrontando alcuni criteri di test obiettivo. 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 per 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 peer, che implica una valutazione soggettiva del contenuto per apprare criticamente la soluzione e fornire suggerimenti per migliorarlo.
  • Test automatizzati: i test automatizzati comportano un test prepreparato valutato automaticamente senza intervento umano. In genere, i test automatizzati controllano parti del codice della soluzione rispetto a benchmark o baseline specifici. I test automatizzati sono più difficili da eseguire e richiedono tempo e impegno per la configurazione. 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 verifiche peer.

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 modifiche di contenuto specifiche e 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.
  • Essere accurati con i test e con la documentazione dei risultati del test. Tuttavia, assicurarsi di evitare test superflui in modo che le procedure di test non rallentano 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 Infrastruttura e Power BI perché sono un'origine upstream per report, dashboard e altri strumenti client e carichi di lavoro di Infrastruttura. 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 ols 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: testare la funzionalità del modello e l'accuratezza con oggetti visivi di trascinamento della selezione.
    • Visualizzazione query DAX: testare l'accuratezza del modello e il codice DAX con query DAX che è possibile salvare e riutilizzare in un secondo momento.
    • Diagnostica query: testare le prestazioni di aggiornamento ottenendo informazioni di diagnostica sulla valutazione delle query in Power Query.
  • Infrastruttura: 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.
  • Strumenti di terze parti: gli strumenti di terze parti consentono di convalidare altri aspetti del modello semantico, fornendo maggiori dettagli o altre funzionalità che facilitano la convalida. Esempi di strumenti di terze parti che facilitano il test dei modelli semantici includono:
    • DAX Studio: testare e ottimizzare le prestazioni del codice DAX ricevendo suddivisioni dettagliate dei tempi delle query DAX e dei piani di query.
    • Editor tabulare: testare ed eseguire il debug dell'accuratezza del codice DAX ricevendo dettagli dettagliati sulla valutazione delle query DAX e sul 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 dipendono dai 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?
  • I tipi di oggetto visivo corretti vengono usati per risolvere la domanda corretta?
  • 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 i report di test includono:
    • Canvas visivo: testare la funzionalità del report usando filtri dei dati, filtri e altri elementi interattivi.
    • Analizzatore prestazioni: testare le prestazioni del report misurando il rendering visivo e i tempi di query DAX. È possibile copiare query DAX visive dall'analizzatore delle prestazioni da usare in altri strumenti e salvare i risultati delle prestazioni per la documentazione.
    • Simulazioni limite di query: testare le prestazioni del report simulando i limiti di memoria nella capacità in cui verrà distribuita.
  • Infrastruttura: 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: testare la funzionalità e la sicurezza dei report durante la distribuzione di report nelle app Power BI e l'impostazione di gruppi di destinatari di app diversi per determinare chi può visualizzare il contenuto. Quando usi gruppi di destinatari delle app, puoi visualizzare in anteprima i report a cui avranno accesso e testare l'esperienza dell'app.
    • Visualizzazione di lettura nell'area di lavoro o nell'app: testare la funzionalità e l'accuratezza del report usandola nello stesso ambiente di un utente.

Nota

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

Importante

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

Testare manualmente eseguendo una verifica peer

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

Nota

La revisione peer è 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 per esaminare la soluzione e offrire di eseguire le stesse operazioni.

Esistono diversi modi per eseguire una revisione peer.

  • 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 per l'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 verifica e un'approvazione formali dei peer prima che le modifiche al contenuto possano passare ai test di accettazione dell'utente. Ciò è dovuto al fatto che il contenuto di scarsa qualità può danneggiare la fiducia nelle soluzioni dati, anche durante i test. Inoltre, la revisione peer può anche trarre vantaggi dalla collaborazione e dalla condivisione delle conoscenze tra i membri del team.

Dopo aver completato un ciclo di revisione peer, è necessario documentare e incorporare eventuali modifiche consigliate. Se necessario, è necessario inviare di nuovo le modifiche per l'approvazione prima di passare al test utente. In genere, sono necessarie più iterazioni di revisione peer 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 i test vengano eseguiti automaticamente prima della distribuzione. I test automatizzati in genere comportano condizioni di test prepreparate 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 informazioni di riferimento e documentazione successive.

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 riesce a un test automatizzato, viene in genere impedito di essere distribuito 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 sono definite in modo non corretto, i test automatizzati non saranno in grado di convalidare gli aspetti corretti del contenuto e si riceveranno pochi vantaggi nell'automazione di questi test.

Suggerimento

I test automatizzati sono particolarmente utili quando si integra 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 richiede 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 l'editor tabulare, 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 dell'editor tabulare insieme ad Azure DevOps o come parte di un altro processo pianificato.
  • Notebook dell'infrastruttura e collegamento semantico:Notebook in 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 Grandi aspettative (GX) per convalidare i dati. Inoltre, è possibile valutare misure e query DAX, quindi testare i risultati rispetto alle baseline 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 in base alle baseline note e quindi eseguire azioni downstream come l'attivazione di avvisi ai proprietari del contenuto.

Suggerimento

Valutare la possibilità di combinare test automatizzati e l'orchestrazione dei modelli semantici. Ad esempio, è possibile eseguire test automatizzati su un'origine dati e un modello semantico prima di un aggiornamento usando notebook o Power Automate. Se i test hanno esito negativo, è possibile impedire l'aggiornamento, che può anche impedire l'aggiornamento di errori o dati non corretti in arrivo 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 i 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 possono completare il flusso e hanno esito negativo quando rilevano parole o immagini specifiche 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 peer, il contenuto può passare ai test degli utenti. Quando gli utenti testano il contenuto, forniscono feedback soggettivo sul fatto che il contenuto soddisfi i requisiti aziendali ed esegua le proprie aspettative, inclusa la 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 per gli utenti di test per convalidare il contenuto. L'app di test deve essere identica all'app che verrà configurata nell'ambiente di produzione. Nel riquadro di spostamento dell'app di test è consigliabile includere collegamenti a documentazione, training e moduli di feedback.
  • Provisioning dell'accesso: identificare un subset di utenti della community che convalideranno la soluzione. Contattare questi utenti e creare un contratto 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 degli elementi di dati nell'area di lavoro di test in modo che gli utenti eseseguono test con i dati più recenti.

Importante

Quando si distribuisce il contenuto in un'area di lavoro di test, è necessario aggiornare manualmente l'app prima che le modifiche ai report e ai dashboard siano visibili per gli 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.

  • Pianificare l'esecuzione della convalida dell'utente.
  • Specificare se la convalida dell'utente è limitata a un periodo specifico o a una parte di un processo iterativo.
  • Creare un metodo per raccogliere commenti e suggerimenti, ad esempio usando Microsoft Forms.
  • Comunicare con gli utenti coinvolti nella convalida della pianificazione e delle 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 dell'osservatorio: i test dell'osservatorio sono brevi sessioni in cui i creatori di contenuti guardano uno o più utenti usano 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 fatica per organizzare e possono essere limitati a funzionalità o parti specifiche di una soluzione. I test dell'osservatorio sono più utili per ottenere un feedback anticipato su una progettazione o un approccio, ad esempio con un modello di verifica (POC).
  • Test del gruppo di focus: i test del gruppo di messa a fuoco sono sessioni limitate organizzate con un piccolo gruppo di utenti che passano insieme al contenuto. Questi gruppi di interesse sono curati per selezionare gli stakeholder chiave e gli esperti in materia che possono fornire il miglior feedback su determinate funzionalità o funzionalità. I test del gruppo di messa a fuoco possono verificarsi su più sessioni interattive. I test del gruppo di attenzione richiedono più tempo e impegno rispetto ai test dell'osservatorio, ma possono fornire feedback più dettagliati su una soluzione.
  • Test di accettazione utente: il test di accettazione utente (UAT) è un processo formale in cui un gruppo più ampio di utenti della community utenti convalida e fornisce feedback asincrono su una soluzione. L'autenticazione definita dall'utente richiede più tempo e impegno per organizzare, ma è il modo più accurato per eseguire test degli utenti. Dopo che gli utenti di test accettano la soluzione e i problemi di feedback vengono risolti, il contenuto può essere distribuito nell'area di lavoro di produzione.

Dopo aver deciso come convalidare il contenuto, è possibile pianificare come distribuirlo in 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, quali test e come eseguirli.
  • Decidere un processo di revisione peer: descrivere chi altro convaliderà il contenuto a parte se stessi.
  • Decidere un approccio al test manuale: decidere quali strumenti e funzionalità verranno usati per convalidare il contenuto creato.
  • Decidere se usare test automatizzati: identificare 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 da convalidare ciò che si prevede.
  • Distribuire 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 per gli 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.
  • Decidere 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 l'accordo con tali persone sulla misura del loro coinvolgimento e delle loro aspettative.
  • Raccogliere commenti e suggerimenti degli utenti: configurare strumenti e processi per raccogliere automaticamente commenti e suggerimenti. Ad esempio, è possibile usare Attività e Planner in Microsoft Teams o Microsoft Forms.
  • Risultati dei test del documento: documentare i risultati di tutta la convalida del contenuto e le eventuali modifiche apportate in seguito ai risultati del test. Assicurarsi che questa documentazione sia facile da trovare.
  • Pianificare la distribuzione in produzione: al termine dei test utente, preparare la distribuzione del contenuto dall'area di lavoro di test all'area di lavoro di produzione.

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