Test di garanzia della qualità perfezionati: un tutorial sul flusso dell'utente

Poiché i prodotti e i servizi vengono implementati sempre più velocemente, il controllo qualità (QA) deve adattarsi all'ambiente in evoluzione, raggiungendo a volte lo stesso livello di copertura in un periodo di tempo più breve. Come evitiamo l'errore di Quantità su Qualità ? Come possiamo coprire di più, aumentare l'efficienza e continuare a essere efficaci nel nostro lavoro?

Sappiamo tutti che i test case richiedono molto tempo per essere creati. Dobbiamo applicare diverse tecniche, tipi di test e documentare precondizioni, passaggi e risultati attesi. Inoltre, dobbiamo creare un piano di test.

Gli specialisti della garanzia della qualità spesso si trovano fuori tempo, soprattutto quando cercano di completare tutte le fasi del processo di QA. Il problema più grande è la fase di pianificazione e progettazione del test, che ruota attorno alla creazione del test case e alla documentazione del test. Possono essere necessarie ore, a volte anche giorni di sforzi per portare a termine tutto il lavoro e, di solito, scelgono di saltare determinati risultati e di riassumere invece, tralasciando informazioni importanti che possono portare all'oblio di un test. Ciò si traduce anche nella perdita del vantaggio della condivisione delle conoscenze.

I test QA tradizionali soddisfano il flusso degli utenti

Sono un grande fan dei casi di test tradizionali e dei piani di test. Non solo aiutano a identificare tonnellate di casi di test, ma documentano anche il prodotto molto bene. Puoi usarli in allenamento e qualsiasi persona del team li capisce. Non devi fare troppo affidamento sull'esperienza affinché qualcuno inizi a testare. I piani di test contengono ulteriori informazioni come il dettaglio dell'ambito, gli elementi di test, le funzionalità che stai testando e quelle che non stai testando. C'è anche un'analisi del rischio che va nel piano di test. Questi sono solo alcuni dei vantaggi, tuttavia, il tempo complessivo necessario in molti casi è troppo lungo.

Lo scopo di un piano di test è un mezzo di comunicazione e un accordo tra le parti interessate del progetto. Aiuta a dettagliare gli obiettivi, le risorse richieste e qualsiasi approccio o strategia per testare il prodotto. Il piano aiuta a garantire che tutto venga pensato e fornisce alle parti interessate la fiducia che il processo di assicurazione della qualità sia investito strategicamente. Non esiste una regola concreta per cui questo piano debba essere lungo 10 pagine. Possiamo ridefinirlo per adattarlo a una squadra frenetica.

L'alternativa è semplificare i tradizionali casi di test e il piano di test in un modo che riduca l'investimento di tempo richiesto ma offra la stessa copertura e documentazione, se non di più, che abbia senso per tutte le parti interessate. Ciò implica un'unica fonte di verità, un flusso di utenti con una svolta. Strutturando e mantenendo un flusso di utenti, avrai la maggior parte del design del tuo test case già fatto per te. Questo può essere applicato a qualsiasi prodotto o team ed è versatile nei dettagli e nella struttura.

L'uso del metodo del flusso ti aiuterà a ottenere tempi di consegna più rapidi con la documentazione del test. Questo non è solo per il controllo qualità manuale, ma anche per l'automazione. Il flusso può anche contribuire ad alcune sezioni del piano di test.

Andando con il flusso

Senza ulteriori indugi, tuffiamoci subito nella creazione di un flusso utente per un semplice sito Web di messaggistica.

Avremo prima bisogno di uno strumento gratuito di mappatura mentale. Personalmente uso XMind. Sentiti libero di scaricare qualsiasi strumento con cui ti senti a tuo agio: utilizzeremo solo funzionalità di base come disegnare un diagramma di flusso, aggiungere "note" ad alcuni argomenti, colorare condizioni diverse e utilizzare etichette.

Il nostro primo passo è capire il prodotto. Di solito, farai riferimento a immagini di mock-up o wireframe. Se nessuno di questi è disponibile, una rapida chiamata di recupero con uno sviluppatore produrrà esattamente quali schermate aspettarsi. Sentiti libero di seguire ed esercitarti mentre procediamo. Il flusso non è limitato solo a un'interfaccia utente e può anche essere utilizzato per mappare chiamate API-API, diagrammi di database, strutture di dipendenza e altro ancora. Si applicano gli stessi principi.

Condizioni, Stati, Azioni

Limitiamo il nostro flusso utilizzando solo tre attori. Avrai una condizione , che è come un utente con un ruolo particolare, una cache svuotata o un utente che accede per la prima volta. In secondo luogo, abbiamo uno State/Page , che è un vero e proprio componente della GUI, come una home page o una finestra di accesso. Poi arriva Action , che è un'interazione fisica dell'utente che fa cambiare lo stato. Vediamo questo in azione.

Analisi dei requisiti

Questa è la nostra homepage, che è lo Stato. Abbiamo due possibili Azioni: Registrati e Accedi.

Quindi, abbiamo la finestra di accesso, un altro stato. Le azioni qui sono Indietro e Accedi. Nota che non classifichiamo i campi di input come azioni. Sei più che benvenuto a farlo. Nella mia esperienza, ho scoperto che quando si lavora su sistemi complessi con una profondità di pochi decimi, diventa un po' difficile da mantenere, ma per applicazioni semplici può essere un'ottima soluzione.

Infine, arriviamo alla dashboard su cui l'utente atterrerà dopo aver eseguito correttamente l'accesso. Qui abbiamo tre azioni: possiamo creare, modificare o eliminare un messaggio.

Ora abbiamo informazioni sufficienti per iniziare il flusso di utenti. Riassumiamo quello che abbiamo. Annotiamo gli stati del prodotto. Da quello che possiamo vedere, ci sono quattro pagine:

1. Pagina iniziale
2. Finestra di accesso
3. Finestra di registrazione
4. Pannello

Annotiamo le nostre azioni su ogni pagina/stato che può essere “interagito” con:

1. Pagina iniziale
   1. Login
   2. Registrati
2. Finestra di accesso
   1. Registrazione
   2. Annulla
3. Finestra di registrazione
   1. TBD (dipende dal prodotto)
4. Pannello
   1. Creare
   2. Modificare
   3. Eliminare

Iniziamo con il nome del prodotto , che può essere modificato per adattarsi al tuo ambiente, ma si adatta alla maggior parte dei team e ai loro prodotti e fornisce anche un buon punto di partenza. Di seguito, noteremo un punto interrogativo accanto a Registrati .

Molte volte, in Agile ti imbatterai in un componente che non è ancora nell'ambito o pianificato per una versione futura. Prendi nota della sua esistenza, ma lascialo sconosciuto fino a quando non avremo maggiori informazioni.

Disegnare il diagramma di flusso

Disegniamo quanto sopra in XMind per assomigliare a:

Noterai che sto semplicemente codificando a colori cosa è uno stato e cosa è un'azione. Ho anche aggiunto una riga dall'azione Annulla alla home page per rappresentare accuratamente quel flusso. Vediamo anche due condizioni quando un utente seleziona "Accedi". Sebbene entrambi vadano alla dashboard, vogliamo comunque testare entrambe le possibili condizioni.

La cosa bella con XMind è che se lavoriamo su un'applicazione grande e complessa, possiamo creare diversi livelli del diagramma, quindi se vuoi suddividere il flusso in più flussi ma tenerli collegati, è molto facile farlo con il collegamento gli argomenti in fogli separati. È possibile selezionare di inserire un collegamento ipertestuale e dal popup della procedura guidata è possibile scegliere uno "Stato" a cui porta l'azione. Ciò significa che se selezioni "Accedi" su XMind e si collega a "Dashboard", il cursore del mouse salterà su "Dashboard", anche se si trova su un foglio diverso. Abbastanza bello.

Ciò che manca al nostro flusso sono le etichette. Assegniamo al prodotto un'etichetta di 0, poiché questa è la radice del flusso. Quindi, per ogni Stato (blu), aggiungiamo un'etichetta S#, per ogni Azione (verde), aggiungiamo un'etichetta A# e, infine, per ogni Condizione (ciano), aggiungiamo un'etichetta C#. Ogni etichetta deve essere unica. Finiamo con quanto segue:

Per tenere traccia dell'ultimo numero utilizzato, poiché man mano che il prodotto cresce, cercare di trovare il numero più alto può essere difficile, lo memorizzo nell'argomento principale del flusso, come di seguito:

Veniamo ora alla parte della creazione di casi di test. Ci concentreremo sui risultati attesi, che sono probabilmente le informazioni più importanti in un test case e fanno parte dei criteri di accettazione della funzionalità. Aggiungerò un titolo per ogni sezione o test e quindi elencherò i risultati attesi sotto di esso. Lo farò solo per un sottoinsieme per mantenere questo articolo conciso:

Quindi, la finestra di accesso:

Quindi, l'azione di accesso:

Sta davvero prendendo forma. Notare i test di confine e di sicurezza aggiunti. Puoi intitolare questo come preferisci, a seconda di quale sia più facile da taggare. A volte contrassegno il titolo con un tipo di test, come Security – JS Inject – Email Field, quindi elenco i risultati previsti di seguito.

Nella maggior parte dei team, riteniamo che la modifica dei requisiti sia una seccatura da mantenere. Non piu. Diciamo che abbiamo appena appreso che a tutti gli utenti per la prima volta deve essere presentata la finestra T e C e devono accettare prima di procedere alla loro dashboard, nessun problema. Possiamo aggiungere lo stato e le azioni in modo relativamente semplice, come di seguito:

Ora vediamo l'impatto dell'aggiunta di un nuovo stato. Nota che la numerazione può essere strana all'inizio, ma finché ricordiamo, i numeri servono solo a identificare in modo univoco ogni attore, proprio come una chiave primaria su un database. Non dimenticare di aggiornare le tue note "Ultimo usato" per tenere traccia dei numeri che usi.

Creazione dei casi di test dal flusso

Dopo tutti questi progressi, arriviamo ora alla parte più semplice: la creazione del test case. Consentitemi di evidenziare alcuni punti importanti. Abbiamo etichette per ogni attore, abbiamo titoli per ogni test e ci aspettiamo risultati per ogni test, con condizioni incorporate come parte del nostro flusso. Sembra la ricetta per un test case, non sei d'accordo?

Tutto ciò che facciamo ora è copiare e incollare ciò che è sul nostro flusso in qualsiasi strumento di gestione dei casi di test, sito Confluence o documento Excel che desideri. Uso ancora il buon vecchio fidato Excel. Tengo un registro di tutti i miei casi di test in un file chiamato "Baseline" - molto originale. Una volta che ho finito di copiare e incollare, finisco con quanto segue:

Sentiti libero di aggiungere colonne per i tipi di test, lo stato del test e le configurazioni del test, se necessario. Le condizioni potrebbero essere meglio posizionate prima dell'azione "Accedi", tuttavia, non esiste un modo giusto o sbagliato per farlo, dipende dalle preferenze personali e dal modo in cui ti organizzi.

Ci sono alcune cose da evidenziare. Uno è che ho unito celle che condividono le stesse informazioni: non c'è bisogno di copiare e incollare ripetutamente, fa perdere tempo ed è più difficile da mantenere. Un altro elemento sono i passaggi. Noterai che due dei test hanno passaggi che incorporano i numeri di stato e di azione. Questo può essere utilizzato quando hai il flusso come parte dell'SDLC nel tuo team. Tutte le parti interessate contribuiscono quindi al flusso fornendo informazioni, modelli, aumentando i rischi, ecc. Ciò significa che indicando i numeri del flusso, chiunque nel team saprà cosa fare e se c'è un nuovo membro del team, è altrettanto facile come "segui il sentiero, fai riferimento alle note".

Questo aiuta anche l'automazione. Puoi assegnare a ogni passaggio o azione un riferimento univoco. Creando un pacchetto di automazione strutturato come il tuo flusso, scoprirai che il framework di automazione che puoi creare ha il potenziale per essere altamente robusto, modulare e compatibile in tutta l'app. Utilizzerà gli oggetti di paging su una scala più ampia, il che ridurrà i tempi di manutenzione e consentirà di sostituire le funzioni di test con quelle nuove.

Il flusso può essere l'unica fonte di verità per tutta la documentazione del prodotto, comprese le specifiche tecniche, le specifiche funzionali, i casi di test, la transizione di stato, i flussi di dati, ecc.

L'approccio semplificato del piano di test

Quindi che dire dei piani di prova?, starai pensando. Questo è semplice. Un piano di test contiene sezioni come:

1. Introduzione e portata
2. Articoli di prova
3. Caratteristiche da testare
4. Caratteristiche da non testare
5. Presupposti
6. Criteri di ingresso
7. Criteri di uscita
8. WBS
9. Rischi
10. Requisiti ambientali

L'introduzione e lo scopo saranno la storia di JIRA o qualsiasi attività o storia in un altro strumento. Gli elementi di test sono semplicemente le versioni del software o i numeri di commit attualmente distribuiti nel tuo ambiente, che puoi collegare al ticket JIRA o durante l'esecuzione del test su Confluence o sullo strumento di gestione del test.

Le funzionalità da testare e le Caratteristiche da non testare sono in realtà i tuoi casi di test. I test case scelti per essere eseguiti per questa storia di JIRA sono "Caratteristiche da testare" e tutto ciò che non è elencato è "Caratteristiche da non testare". Molto semplicemente, elenca gli stati e le azioni che testerai sul ticket della storia.

Presupposti, rischi e persino requisiti ambientali possono essere compilati in un documento o aggiunti ai commenti su JIRA, a volte anche inseriti su Confluence e collegati alla storia.

Una WBS è una stima che assegni alla storia in termini di story point o ore, a seconda del tuo progetto. I criteri di entrata e di uscita faranno già parte della storia.

Se vuoi essere vicino ai piani di test "tradizionali", puoi chiedere allo sviluppatore o ad altre parti interessate di commentare la storia con un Sì o un No per vedere se sono d'accordo con il piano di QA o meno. Questo tecnicamente funge da firma digitale. Tutto questo può essere incluso nel processo di QA piuttosto facilmente e ti aiuta a semplificare la tua documentazione di QA.

Cosa abbiamo imparato?

Il flusso di utenti con l'approccio di cui sopra e i piani di test semplificati per utilizzare gli strumenti disponibili oggi ci aiuteranno a ridurre il lavoro ripetitivo e ad aiutare il QA a ottenere tempi di risposta più rapidi senza sacrificare la qualità.

Questo approccio è stato determinante nel guidarmi a rimanere organizzato, coprire ogni base e creare documentazione comprensibile a tutto il team. In Agile, questo sarà davvero utile e la parte migliore è che stiamo ancora rispettando uno degli approcci Agile: "Semplificare la documentazione".

Spero davvero che le informazioni siano state utili. Dipende tutto da te come lettore. Questo non è un insieme di regole concrete da seguire, queste sono solo linee guida per darti spunti per crescere e migliorare la tua efficienza. Nessuna tecnica si adatta a ogni progetto, team o prodotto, ma potrebbe aprire la strada a un'altra idea innovativa.