Che cosè il test di accettazione dellutente (UAT): una guida completa

Scopri cosè il test di accettazione dellutente (UAT) , Insieme alla sua definizione, tipi, passaggi ed esempi:

La mia regola numero uno quando provo a capire un nuovo concetto è questa: il nome sarà sempre pertinente e per lo più un significato letterale (nel contesto tecnico).

Scoprire di cosa si tratta mi darà una prima comprensione e mi aiuterà a iniziare.

= > Fare clic qui per una serie completa di tutorial sul piano di test

Mettiamo alla prova questo concetto.

= > Leggi tutti i tutorial nella nostra serie di test di accettazione.

Che cosè il test di accettazione dellutente?

Sappiamo cosa è il test, accettazione significa approvazione o accordo. Lutente nel contesto di un prodotto software è il consumatore del software o la persona che ne ha richiesto la creazione (cliente).

Quindi, seguendo la mia regola, la definizione sarà :

Il test di accettazione dellutente (UAT), noto anche come beta o test dellutente finale, è definito come il test del software da parte dellutente o del cliente per determinare se può essere accettato o meno. Questo è il test finale eseguito una volta completati i test funzionali, di sistema e di regressione.

Lo scopo principale di questo test è convalidare il software rispetto ai requisiti aziendali. Questa convalida viene eseguita dagli utenti finali che hanno familiarità con i requisiti aziendali.

UAT, alpha e beta test sono diversi tipi di test di accettazione.

Poiché il test di accettazione dellutente è lultimo test che viene eseguito prima che il software sia disponibile, ovviamente questo è il ultima possibilità per il cliente di testare il software e misurare se è adatto allo scopo.

Quando viene eseguito?

Questo è in genere lultimo passaggio prima che il prodotto sia disponibile o prima che venga accettata la consegna del prodotto. Questa operazione viene eseguita dopo che il prodotto stesso è stato accuratamente testato (ovvero dopo il test del sistema).

Chi esegue lUAT?

Utenti o cliente: potrebbe essere qualcuno che sta acquistando un prodotto ( nel caso di software commerciale) o qualcuno che ha fatto costruire un software personalizzato tramite un fornitore di servizi software o lutente finale se il software è messo a loro disposizione in anticipo e quando viene richiesto il loro feedback.

Il team può essere composto da beta tester oppure il cliente deve selezionare i membri UAT internamente da ogni gruppo dellorganizzazione in modo che ogni ruolo utente possa essere testato di conseguenza.

Need For User Acceptance Testing

Sviluppatori e tester funzionali sono persone tecniche che convalidano il software rispetto alle specifiche funzionali. Interpretano i requisiti in base alle loro conoscenze e sviluppano / testano il software (qui è limportanza della conoscenza del dominio).

Questo software è completo secondo le specifiche funzionali ma ci sono alcuni requisiti e processi aziendali che sono noto solo agli utenti finali o non riesce a comunicare o viene interpretato male.

Questo test gioca un ruolo importante nel convalidare se tutti i requisiti aziendali sono soddisfatti o meno prima di rilasciare il software per luso sul mercato. Lutilizzo di dati in tempo reale e casi duso reali rendono questo test una parte importante del ciclo di rilascio.

Molte aziende che hanno subito grosse perdite a causa di problemi post-rilascio conoscono limportanza di un test di accettazione utente di successo. Il costo per correggere i difetti dopo il rilascio è molte volte maggiore rispetto a prima.

UAT è davvero necessario?

Dopo aver eseguito carichi di test di sistema, integrazione e regressione ci si potrebbe chiedere la necessità di questo test. In realtà, questa è la fase più importante del progetto in quanto questo è il momento in cui gli utenti che effettivamente utilizzeranno il sistema convalideranno il sistema per la sua adattabilità allo scopo.

UAT è un test fase che dipende in gran parte dalla prospettiva degli utenti finali e dalla conoscenza del dominio di un reparto che rappresenta gli utenti finali.

In effetti, sarebbe davvero utile per i team aziendali, se sono stati coinvolti nel progetto abbastanza presto, in modo che possano fornire le loro opinioni e contributi che aiuterebbero un utilizzo efficace del sistema nel mondo reale.

Processo di test di accettazione degli utenti

Il Il modo più semplice per comprendere questo processo è pensare a questo come a un progetto di test autonomo, il che significa che avrà il piano, la progettazione e le fasi di esecuzione.

I seguenti sono i prerequisiti prima della fase di pianificazione inizia:

# 1) Raccogli i criteri di accettazione chiave

In termini semplici, i criteri di accettazione sono un elenco di questi ngs che verranno valutati prima di accettare il prodotto.

Potrebbero essere di 2 tipi:

(i) Funzionalità dellapplicazione o correlate allattività

Idealmente, tutte le funzionalità aziendali chiave dovrebbero essere convalidate, ma a causa di vari motivi, compreso il tempo, non è pratico fare tutto. Pertanto, uno o due incontri con il cliente o gli utenti che saranno coinvolti in questo test possono darci unidea di quanto test sarà coinvolto e quali aspetti saranno testati.

(ii) Contrattuale – Non entreremo in questo argomento e il coinvolgimento del team QA in tutto questo è quasi nulla. Il contratto iniziale che viene redatto anche prima dellinizio dellSDLC viene riesaminato e viene raggiunto un accordo sul fatto che tutti gli aspetti del contratto siano stati consegnati o meno.

Ci concentreremo solo sulla funzionalità dellapplicazione .

# 2) Definisci lambito del coinvolgimento del QA.

Il ruolo del team QA è uno dei seguenti:

(i) Nessun coinvolgimento – Questo è molto raro.

(ii) Assistere in questo test – La maggior parte Comune. In questo caso, il nostro coinvolgimento potrebbe essere la formazione degli utenti UAT su come utilizzare lapplicazione ed essere in standby durante questo test per assicurarci di poter aiutare gli utenti in caso di difficoltà. O in alcuni casi, oltre a essere in standby e ad assistere, potremmo condividere le loro risposte e registrare i risultati o registrare bug ecc., Mentre gli utenti eseguono il test vero e proprio.

(iii) Eseguire UAT e presentare i risultati – Se questo è il caso, gli utenti indicheranno le aree dellAUT che vogliono valutare e la valutazione stessa viene eseguita dal team di QA. Una volta fatto, i risultati vengono presentati ai clienti / utenti che decideranno se i risultati che hanno in mano sono sufficienti o meno e in base alle loro aspettative per accettare lAUT. La decisione non è mai quella del team QA.

A seconda del caso, decidiamo quale sia lapproccio migliore.

Gli obiettivi e le aspettative principali:

Di solito, lUAT è intrapreso da un esperto in materia (PMI) e / o un utente aziendale, che potrebbe essere il proprietario o il cliente di un sistema in prova. Analogamente alla fase di test del sistema, la fase UAT comprende anche fasi religiose prima che venga portata alla chiusura.

Le attività chiave di ciascuna fase UAT sono definite di seguito:

Governance UAT

In modo simile ai test di sistema, per lUAT viene applicata una governance efficace per garantire che i controlli di qualità solidi insieme ai criteri di ingresso e di uscita definiti (forniti di seguito **).

** Si noti che è solo una guida. Questo potrebbe essere modificato in base alle esigenze e ai requisiti del progetto.

Pianificazione del test UAT

Il processo è quasi lo stesso del normale piano di test nella fase di sistema.

Lapproccio più comune seguito nella maggior parte dei progetti è pianificare insieme le fasi di test del sistema e dellUAT. Per ulteriori informazioni sul piano di test UAT insieme a un campione, consultare le sezioni UAT del documento del piano di test allegato.

Piano di test di accettazione utente

(Questo è lo stesso che faresti trova sul nostro sito anche le serie di formazione QA).

Fai clic sullimmagine sottostante e scorri verso il basso per trovare il documento di esempio del piano di test in vari formati. In quel modello controlla la sezione UAT.

Le date, lambiente, gli attori (chi), i protocolli di comunicazione, i ruoli e le responsabilità, i modelli, i risultati e il loro processo di analisi, i criteri di entrata-uscita – tutto questo e qualsiasi altra cosa pertinente si troverà nel piano di test UAT.

Sia che il team QA stia partecipando, partecipando parzialmente o non partecipando affatto a questo test, è nostro compito pianificare questa fase e assicurati che tutto sia preso in considerazione.

= > Ecco un documento di esempio del piano di test di accettazione dellutente

Progetto del test di accettazione dellutente

In questo passaggio vengono utilizzati i criteri di accettazione raccolti dagli utenti. I campioni potrebbero apparire come mostrato di seguito.

(Questi sono estratti da CSTE CBOK. Questo è uno dei migliori riferimenti disponibili su questo test.)

Modello di test di accettazione dellutente:

In base ai criteri, noi (team QA) forniamo agli utenti un elenco di casi di test UAT. Questi casi di test non sono diversi dai nostri normali casi di test di sistema. Sono solo un sottoinsieme in quanto testiamo tutte le applicazioni e non solo le aree funzionali chiave.

Oltre a questi, i dati, i modelli per registrare i risultati dei test, le procedure amministrative, il meccanismo di registrazione dei difetti, ecc., deve essere in atto prima di passare alla fase successiva.

Esecuzione del test

Di solito, quando possibile, questo test avviene in una conferenza o in una sala di guerra impostare il luogo in cui gli utenti, il PM, i rappresentanti del team QA si siedono insieme per un giorno o due e lavorano su tutti i casi di test di accettazione.

Oppure, nel caso in cui il team QA esegue i test, eseguiamo il test casi sullAUT.

Dopo aver eseguito tutti i test e aver ottenuto i risultati, viene presa la decisione di accettazione. Questa è anche chiamata decisione Go / No-Go. Se gli utenti sono soddisfatti, si tratta di un passaggio oppure di un rifiuto.

Il raggiungimento della decisione di accettazione è in genere la fine di questa fase.

Strumenti & Metodologie

In genere, il tipo di strumenti software utilizzati durante questa fase di test è simile agli strumenti utilizzati durante lesecuzione di test funzionali.

Strumenti:

Poiché questa fase implica la convalida dellintero flusso end-to-end dellapplicazione, potrebbe essere difficile disporre di uno strumento per automatizzare completamente questa convalida. Tuttavia, in una certa misura, saremmo in grado di sfruttare gli script automatizzati sviluppati durante il test del sistema.

Simile al test del sistema, gli utenti utilizzerebbero anche la gestione dei test e strumenti di gestione dei difetti come QC, JIRA, ecc. gli strumenti possono essere configurati per accumulare i dati per la fase di accettazione dellutente.

Metodologie:

sebbene le metodologie convenzionali come utenti aziendali specifici che eseguono lUAT del prodotto siano ancora rilevanti, in un contesto veramente globale nel mondo come oggi, i test di accettazione degli utenti a volte devono coinvolgere diversi clienti in tutti i paesi in base al prodotto.

Ad esempio, un sito web di e-commerce sarebbe utilizzato dai clienti di tutto il mondo. In scenari come questo, il crowd testing sarebbe la migliore opzione praticabile.

Crowd testing è una metodologia in cui persone provenienti da tutto il mondo possono partecipare e convalidare lutilizzo del prodotto e fornire suggerimenti e raccomandazioni.

Le piattaforme di test di massa sono state costruite e vengono utilizzate da molte organizzazioni ora. Un sito Web o un prodotto che deve essere testato in massa è ospitato nella piattaforma ei clienti possono nominarsi per eseguire la convalida. I feedback forniti vengono quindi analizzati e classificati in ordine di priorità.

La metodologia di Crowd Testing si sta dimostrando più efficace in quanto il polso del cliente in tutto il mondo può essere facilmente compreso.

UAT in Agile Environment

Lambiente agile è di natura più dinamica. In un mondo agile, gli utenti aziendali saranno coinvolti durante gli sprint del progetto e il progetto verrebbe migliorato in base ai cicli di feedback da loro.

Allinizio del progetto, gli utenti aziendali sarebbero gli stakeholder chiave per fornire requisiti aggiornando così il backlog del prodotto. Durante la fine di ogni sprint, gli utenti aziendali parteciperebbero alla demo dello sprint e sarebbero disponibili a fornire qualsiasi feedback.

Inoltre, prima del completamento dello sprint sarebbe stata pianificata una fase UAT in cui gli utenti aziendali farebbero il loro convalide.

I feedback ricevuti durante lo sprint demo e lo sprint UAT, vengono raccolti e aggiunti al backlog del prodotto che viene costantemente rivisto e prioritario. Pertanto, in un mondo agile, gli utenti aziendali sono più vicini al progetto e valutano lo stesso per il suo utilizzo più frequentemente a differenza dei tradizionali progetti a cascata.

UAT Team – Ruoli & Responsabilità

Una tipica organizzazione UAT avrebbe i seguenti ruoli e responsabilità. Il team UAT sarebbe supportato dal project manager, dai team di sviluppo e test in base alle loro esigenze.

7 sfide dellUAT E piano di mitigazione

Non importa se fai parte di una release da un miliardo di dollari o di un team di startup, dovresti superare tutte queste sfide per fornire software di successo per lutente finale.

# 1) Configurazione dellambiente e processo di distribuzione:

Lesecuzione di questo test nello stesso ambiente utilizzato dal team di test funzionali finirà sicuramente per trascurare i casi duso del mondo reale. Inoltre, attività di test cruciali come il test delle prestazioni non possono essere eseguite su un ambiente di test con dati di test incompleti.

Per questo test dovrebbe essere impostato un ambiente simile alla produzione.

Una volta che lambiente UAT è separato dallambiente di test, è necessario controllare efficacemente il ciclo di rilascio. Il ciclo di rilascio incontrollato può portare a versioni software differenti in ambiente di test e UAT. Un prezioso tempo per i test di accettazione viene sprecato quando il software non viene testato sulla versione più recente.

Nel frattempo, il tempo necessario per il monitoraggio dei problemi su una versione del software errata è elevato.

# 2) Test Pianificazione:

Questo test dovrebbe essere pianificato con un chiaro piano di test di accettazione nella fase di analisi e progettazione dei requisiti.

Nella pianificazione della strategia, dovrebbe essere identificato il set di casi duso del mondo reale per lesecuzione. È molto importante definire gli obiettivi di test per questo test poiché unesecuzione di test completa non è possibile per applicazioni di grandi dimensioni in questa fase di test. Il test deve essere eseguito assegnando prima la priorità agli obiettivi di business critici.

Questo test viene eseguito alla fine del ciclo di test. Ovviamente è il periodo più critico per il rilascio del software. Il ritardo in una qualsiasi delle fasi precedenti di sviluppo e test consumerà il tempo dellUAT.

Una pianificazione impropria del test, nel peggiore dei casi, porta a una sovrapposizione tra il test del sistema e lUAT. A causa della riduzione del tempo e della pressione per rispettare le scadenze, il software viene distribuito in questo ambiente anche se i test funzionali non vengono completati. Gli obiettivi principali di questo test non possono essere raggiunti in tali situazioni.

Il piano di test UAT deve essere preparato e comunicato al team ben prima di iniziare questo test. Questo li aiuterà nella pianificazione dei test, nella scrittura di casi di test & script di test e nella creazione di un ambiente UAT.

# 3) Gestire i nuovi requisiti aziendali come incidenti / difetti:

Le ambiguità nei requisiti vengono colte nella fase UAT. I tester UAT trovano problemi che sorgono a causa di requisiti ambigui (esaminando linterfaccia utente completa che non era disponibile durante la fase di raccolta dei requisiti) e la registrano come un difetto.

Il cliente si aspetta che questi vengano risolti nella versione corrente senza considerare il tempo per le richieste di modifica. Se la direzione del progetto non prende una decisione tempestiva su queste modifiche dellultimo minuto, ciò potrebbe portare al fallimento del rilascio.

# 4) Tester inesperti o tester senza conoscenza del business:

Quando non esiste un team permanente, lazienda seleziona il personale UAT dai vari reparti interni.

Anche se il personale conosce bene le esigenze aziendali, o se non è formato per i nuovi requisiti che vengono in fase di sviluppo, non possono eseguire UAT efficaci. Inoltre, un team aziendale non tecnico potrebbe incontrare molte difficoltà tecniche nellesecuzione dei casi di test.

Nel frattempo, lassegnazione di tester alla fine del ciclo UAT non aggiunge alcun valore al progetto. Poco tempo per formare lo staff UAT può aumentare significativamente le possibilità di successo dellUAT.

# 5) Canale di comunicazione improprio:

La comunicazione tra sviluppo remoto, test e team UAT è più difficile . La comunicazione e-mail è spesso molto difficile quando si dispone di un team tecnico offshore. Una piccola ambiguità nei rapporti sugli incidenti può ritardare la sua risoluzione di un giorno.

Una corretta pianificazione e una comunicazione efficace sono fondamentali per una collaborazione efficace in team. I team di progetto dovrebbero utilizzare uno strumento basato sul Web per registrare difetti e domande. Ciò contribuirà a distribuire il carico di lavoro in modo uniforme ed evitare di segnalare problemi duplicati.

# 6) Chiedere al team di test funzionali di eseguire questo test:

Non cè situazione peggiore che chiedere il test funzionale team per eseguire lUAT.

I clienti scaricano la loro responsabilità sul team di test a causa della mancanza di risorse. Lintero scopo di questo test viene compromesso in questi casi. Una volta che il software è attivo, gli utenti finali individueranno rapidamente i problemi che non sono considerati scenari del mondo reale dai tester funzionali.

Una soluzione a questo è assegnare questo test a persone dedicate tester con conoscenze aziendali.

# 7) Il gioco della colpa

A volte gli utenti aziendali cercano solo di trovare ragioni per rifiutare il software. Potrebbe essere il loro selfdom mostrare quanto sono superiori o incolpare il team di sviluppo e test per ottenere rispetto nel team aziendale. Questo è molto raro, ma accade in team con politica interna.

È molto difficile affrontare tali situazioni. Tuttavia, costruire un rapporto positivo con il team aziendale aiuterebbe sicuramente a evitare il gioco della colpa.

Spero che queste linee guida ti aiuteranno sicuramente a eseguire un piano di accettazione dellutente di successo superando varie sfide. Una corretta pianificazione, comunicazione, esecuzione e un team motivato sono le chiavi per il successo dei test di accettazione da parte degli utenti.

Test di sistema vs test di accettazione da parte degli utenti

Il coinvolgimento del team di test inizia abbastanza presto nel progetto fin dalla fase di analisi dei requisiti.

Durante tutto il ciclo di vita del progetto, viene eseguita una sorta di convalida per il progetto, ovvero test statico, test unitario, test di sistema, test di integrazione, test end to end o test di regressione. Questo ci consente di comprendere meglio il test eseguito nella fase UAT e quanto sia diverso dagli altri test eseguiti in precedenza.

Anche se vediamo le differenze in SIT e UAT, è importante sfruttare le sinergie ma mantengono comunque lindipendenza tra le due fasi, il che consentirebbe un time-to-market più rapido.

Conclusione

# 1) UAT non riguarda le pagine, i campi o i pulsanti. Lassunto di base anche prima dellinizio di questo test è che tutte le cose di base siano testate e funzionino bene. Dio non voglia, gli utenti trovano un bug così elementare: è una brutta notizia per il team di controllo qualità. 🙁

# 2) Questo test riguarda lentità che è lelemento principale dellazienda.

Lascia che ti faccia un esempio: se lAUT è un sistema di ticketing, UAT non riguarderà la ricerca del menu che apre una pagina, ecc. Riguarda i biglietti e la loro prenotazione, gli stati che può prendere, il suo viaggio attraverso il sistema, ecc.

Un altro esempio, se il sito è un sito di un concessionario di automobili, lattenzione si concentra sull “automobile e le sue vendite” e non proprio sul sito. Pertanto, lattività principale è ciò che viene verificato e convalidato e chi è meglio farlo rispetto al proprietari di attività commerciali. Ecco perché questo test ha più senso quando il cliente è coinvolto in misura maggiore.

# 3) Anche lUAT è una forma di test fondamentale, il che significa che ci sono buone possibilità di identificare alcuni bug anche in questa fase. A volte accade. A parte il fatto che si tratta di una grave escalation per il team QA, i bug UAT di solito significano una riunione per sedersi e discutere come gestirli come segue durante questo test di solito non cè tempo per risolvere e ripetere il test.

La decisione potrebbe essere:

• Spingere la data di go-live, risolvere prima il problema e poi vai avanti.
• Lascia il bug così comè.
• Consideralo come parte della richiesta di modifica per le versioni future.

# 4) UAT è classificato come Alpha e Beta test, ma questa classificazione non è così importante nel contesto dei tipici progetti di sviluppo di software in un settore basato sui servizi.

• Alpha test è quando lUAT viene eseguito nellambiente del software builder ed è più significativo nel contesto del commerciale off the shelf software.
• Il beta test è quando lUAT viene eseguito nellambiente di produzione o nellambiente del cliente. Questo è più comune per le applicazioni rivolte ai clienti. Gli utenti qui sono i clienti effettivi come te e me in questo contesto.

# 5) La maggior parte delle volte in un normale progetto di sviluppo software, lUAT viene eseguita nellambiente QA se esiste non è un ambiente di staging o UAT.

In breve, il modo migliore per scoprire se il tuo prodotto è accettabile e adatto allo scopo è metterlo effettivamente di fronte agli utenti.

Le organizzazioni stanno entrando nel modo Agile di fornire, gli utenti aziendali sono sempre più coinvolti ei progetti vengono migliorati e consegnati tramite cicli di feedback. Fatto tutto, la fase di accettazione dellutente è considerata il punto di accesso allimplementazione e alla produzione.

Qual è stata la tua esperienza con lUAT? Eri in standby o hai testato per i tuoi utenti? Gli utenti hanno riscontrato problemi? Se sì, come li hai affrontati?

= > Leggi anche TUTTI i tutorial di questa serie qui

= > Visita qui per la serie completa di tutorial sul piano di test