In questo articolo affrontiamo l’argomento relativo alla metodologia di QA del software. Sempre più utenti desiderano infatti approfondire questa tecnologia, ed ecco perché vogliamo offrire loro delle istruzioni chiare e pratiche sul testing QA.
Addentrandoci sempre più, riteniamo che questo argomento debba essere affrontato da più punti di vista, coprendo sia gli aspetti tecnici che quelli commerciali e mostrando i vari modi in cui i due interagiscono.
Andiamo a vedere da vicino la metodologia QA, certi che i nostri consigli potranno aiutare aziende e agenzie ad allineare i loro flussi di lavoro in modo più accurato, garantendo una maggiore sicurezza e un migliore controllo dei vari processi.
Gli obiettivi principali sono i seguenti:
- Delineare lo scopo dell’AQ rispetto alla CQ
- Spiegare il ruolo di un tester QA all’interno del ciclo di vita dello sviluppo del progetto
- Descrivere la metodologia di test QA/QC che aiuta a garantire la consegna dei progetti in modo efficace e puntuale
Le linee guida elencate di seguito derivano da numerosi progetti di sviluppo e collaudo di siti web e applicazioni web. Tuttavia, gli stessi principi si possono applicare ad altri settori dello sviluppo software, rendendoli compatibili con le esigenze degli specialisti della QA in tutti i settori.
Definizione di QC / QA
Che cos’è la QC?
La QC è l’individuazione e il controllo dei difetti. Una parte integrante del lavoro del tester QC è l’identificazione dei problemi e la “segnalazione di bug” (vedi sotto). Questo processo viene definito “rilevamento dei difetti”.
Che cos’è la QA?
La QA è un metodo per prevenire errori e difetti durante lo sviluppo. Il compito di un tester QA è quello di adottare misure per evitare potenziali problemi. Questo processo viene definito “prevenzione dei difetti”.
La centralità della QA/QC nel ciclo di vita dello sviluppo del progetto
Di seguito sono riportate le principali fasi del progetto di sviluppo del software con la descrizione delle attività di QA/QC necessarie in ciascuna fase. Si tenga presente che la strategia di test può variare a seconda delle specificità del progetto.
In generale, sia il rilevamento che la prevenzione dei difetti avvengono in determinate fasi del progetto e svolgono un ruolo importante nel ciclo di sviluppo di un progetto.
Rilevamento dei difetti
Il rilevamento dei difetti, noto anche come CQ, è la parte del ciclo di vita del test del software durante la quale gli ingegneri addetti al test esaminano il progetto in corso (live o in fase di sviluppo), identificando e segnalando i difetti. In questo caso si applica la stessa logica descritta nella sezione sulla metodologia QA:
- Testare prima l’output funzionale
- Successivamente, si procede con la rappresentazione dei dati, la progettazione e il test di compatibilità cross-browser
Tipi di bug da ricercare
Cosa viene considerato un bug? Un bug nello sviluppo del software è un problema che impedisce la consegna del progetto o Un problema che non consente al cliente di gestire la propria attività come previsto.
Di seguito sono elencate le principali problematiche che devono essere affrontate attraverso vari tipi di test. Cercate di trovarli, descriverli e segnalarli nel modo più accurato possibile.
Contenuto
A cosa prestare attenzione
- Deviazioni nella copia testuale o visiva dal risultato atteso
Cosa controllare
- Elementi dell’interfaccia utente
- Notifiche
- CTA
- Altri elementi testuali e di design che non corrispondono allo scopo del progetto/pagina previsto
- Errori di ortografia
- Errori di punteggiatura e maiuscole
- Contenuti non tradotti
- Contenuti demo e di prova (sia testo che immagini)
- Parti mancanti del contenuto della pagina (sia testo che immagini)
Immagine
A cosa prestare attenzione
- Deviazioni del layout visivo del sito rispetto a quanto confermato nei progetti iniziali o nella guida di riferimento
Cosa controllare
- Revisione pixel-perfetta degli spazi tra gli elementi
- Revisione pixel-perfetta degli elementi di design responsive
- Scostamenti nei colori, nelle dimensioni, nel posizionamento, nei margini, nell’ordine degli elementi
- Incoerenze visive in tutta l’interfaccia utente
- Effetti/stato di avanzamento degli elementi selezionati errati o mancanti
- Contenuti disallineati o che non si adattano all’area in qualche altro modo
- Mancanza di elementi di design, ad esempio particolari sfondi o colori di sfondo
- Revisione di tutti gli elementi attivi come link, pulsanti, campi di input, messaggi di errore per garantire una rappresentazione corretta
Cross-browser
A cosa prestare attenzione
- Il sito web viene visualizzato in modo diverso nei vari browser/versioni di browser, al punto da risultare dannoso per l’azienda
Cosa controllare
- Comparsa di artefatti visivi inaspettati
- Elementi funzionali non disponibili
- Problemi di prestazioni, come tempi di caricamento più lunghi
Cross-device
A cosa prestare attenzione
- Deviazioni particolari di comportamento del dispositivo
Cosa controllare
- Elementi che si visualizzano/comportano in modo diverso nei diversi sistemi operativi
- Elementi che si visualizzano/comportano in modo diverso tra telefono, tablet e desktop
Funzionalità
A cosa prestare attenzione
- Comportamenti che non funzionano come previsto o che non funziona affatto
NB: Quando si segnalano bug funzionali, un ingegnere addetto ai test del software deve descrivere il problema e i passaggi specifici per ricreare il comportamento difettoso.
Cosa controllare
- Filtraggio errato del prodotto
- Enumerazione errata degli elementi
- Pagine 404
- Immagini della galleria dei prodotti rotte o mancanti
- Incoerenza dei dati dei prodotti nelle diverse pagine (ad esempio, prezzi errati)
- Funzionalità di iscrizione via e-mail non funzionante
- Funzionalità di ricerca non funzionante
- Funzionalità di ordine del prodotto non funzionante
- Funzionalità di checkout non funzionante
- Funzionalità di login non funzionante
- Incoerenza dei dati tra back-end e front-end (ad es. aliquote IVA, prezzi speciali, ecc.)
Prestazioni
A cosa prestare attenzione
- Lentezza nel caricamento della pagina/risposta.
Nota: una regola generale è che nessuna operazione può richiedere più di 2-3 secondi per essere eseguita. Un tempo di risposta più lungo è quasi sicuramente segno di un problema tecnologico di fondo.
Cosa cercare
- Caricamento della prima pagina (provare in incognito, rimuovere tutta la cache)
- Risultati della ricerca
- Filtraggio dei prodotti
- Paginazione
- Immagini e banner di grandi dimensioni (non possono superare i 600-700 Kb)
- Primo caricamento della pagina dell’inserzione
- Aggiunta di un prodotto al carrello
- Effettuare un ordine
- Accesso e disconnessione dall’account del cliente
Struttura di una segnalazione di bug
Di seguito sono elencati gli elementi principali di una segnalazione di bug con relative descrizioni. Seguendo queste linee guida, gli specialisti del testing potranno fornire ai loro team rapporti di bug chiari e uniformi.
Titolo dell’anomalia/bug
Il titolo deve descrivere il problema in modo chiaro e conciso. Deve rendere evidente se il bug è funzionale, visivo, cross-browser, cross-device, di contenuto o di prestazioni.
Esempi:
- Il cliente non riesce ad accedere
- Il link per l’annullamento dell’iscrizione non funziona
- Traduzioni mancanti nelle FAQ.
Passi per ricreare il problema
Questa sezione deve fornire istruzioni passo-passo su come arrivare al punto in cui il problema può essere sperimentato.
Cosa tenere a mente:
- Assicurarsi di indicare gli input di dati rilevanti
- Assicurarsi di elencare le versioni del browser e del dispositivo per i problemi cross-browser e cross-device.
- Fornire una chiara indicazione del comportamento non corretto che deve essere ricreato.
- Risultati attesi
Questa sezione della segnalazione di bug descrive il comportamento risultante dopo la risoluzione del problema. L’obiettivo è quello di fornire agli sviluppatori una chiara comprensione di ciò che è richiesto loro per completare il compito.
Il risultato atteso può essere descritto sotto forma di collegamento a modelli di progettazione, output di dati specifici, sblocco di un percorso utente o disponibilità di una particolare funzionalità.
Dettagli del test
Questa sezione di una segnalazione di bug deve contenere le informazioni aggiuntive necessarie per comprendere la portata del problema.
Ambiente
Dettagli dell’ambiente di test, che descrivono il tipo di dispositivo, il modello di dispositivo, i dettagli del browser, il sistema operativo.
Schermate
Screenshot del bug con frecce e altri elementi visivi per evidenziare l’area problematica.
Video (opzionale)
L’aggiunta di un video di cattura dello schermo può essere utile per dimostrare rapidamente la sequenza specifica dei passaggi necessari per ricreare il problema.
Logs (facoltativo)
Possono e devono essere aggiunti se aiutano davvero a capire il problema. Assicuratevi di aggiungere solo i log della console che sono apparsi nel corso del malfunzionamento descritto.
Flusso di lavoro per la segnalazione dei bug
Segnalazione di bug o fallimento di un’attività
Nel contesto del flusso di lavoro per la segnalazione dei bug, gli sforzi di QA/QC possono essere suddivisi in due grandi categorie.
Test libero
In questa modalità, uno specialista di test ha un modulo, un sito web o un’applicazione da esplorare. In questo caso, la segnalazione dei problemi comporta la creazione di tutte le segnalazioni di bug necessarie, che coprono ogni problema scoperto.
Test di un compito specifico per convalidare il lavoro di qualcun altro
In questa modalità lo specialista di test ha un paio di scelte in più da fare:
- Se tutto funziona come previsto, il compito può essere contrassegnato come “QA superato”.
- Se il compito presenta dei problemi, ci sono due opzioni aggiuntive
- Il compito viene contrassegnato come “QA non superato” con informazioni aggiuntive che ne descrivono le ragioni. Questa opzione viene utilizzata quando il risultato chiave atteso non è stato raggiunto. Usatela per assicurarvi che gli errori critici non passino alla fase successiva del progetto.
- Il compito è contrassegnato come “QA superato”, con l’aggiunta di ulteriori segnalazioni di bug per documentare gli aspetti che devono essere ulteriormente corretti. Questa opzione viene utilizzata quando l’obiettivo aziendale chiave del compito è stato completato, ma ci sono alcuni problemi aggiuntivi che sono stati scoperti durante il processo di test. Utilizzatela per assicurarvi che i problemi non critici non blocchino l’intero progetto.
Una segnalazione di bug per ogni problema
Una regola generale prevede che il tester crei un bug report separato per ogni problema scoperto. Questo è consigliabile per avere un quadro chiaro dello stato attuale e dei progressi del progetto e per stimare con precisione gli sforzi necessari per avvicinarlo al completamento.
Naturalmente, ci sono delle eccezioni a questa regola. Per esempio, i bug minori relativi allo stesso problema possono e devono essere raggruppati insieme per evitare un disordine ridondante.
Esempio: Si potrebbero facilmente riunire sotto lo stesso compito i problemi relativi allo spessore dei bordi, al carattere del pulsante di iscrizione e all’effetto hover di un modulo di iscrizione alla newsletter.
PREVENZIONE DEI DIFETTI
La prevenzione dei difetti, nota anche come assicurazione della qualità (QA), è la parte del ciclo di vita del test del software che si svolge prima o contemporaneamente alle altre attività di sviluppo. In genere, con la QA vogliamo fare un passo indietro nel processo di realizzazione del progetto e iniziare a capire come prevenire gli errori, prima che inizi il lavoro di sviluppo.
Chiarezza nella definizione dei compiti
In qualità di specialista QA, è importante che:
- capire il risultato atteso del compito,
- avere accesso a tutti i materiali di progetto rilevanti (ad esempio, i modelli di progettazione)
- capire come viene gestita una determinata funzionalità attraverso il back-end, nonché la sua rappresentazione prevista per il front-end.
Una task QA ben definita è quella che fornisce dati sufficienti allo specialista QA su cosa deve testare e come.
Una task QA ben definita è quella che delinea chiaramente i requisiti e descrive un approccio specifico alla soluzione.
Considerate i seguenti attributi di un compito ben definito:
- Nome del compito azionabile
- Viene fornito il background
- Struttura chiara del compito che include la descrizione del compito, le attività concrete da svolgere e la sezione “come testare”.
- Breve e preciso, facile da capire
- I casi limite sono coperti
- L’ambito di questo compito è limitato e le relazioni con gli altri compiti sono delineate.
Che cos’è un caso di test-case?
Un caso di test è una specifica degli input, delle condizioni di esecuzione, delle procedure di test e dei risultati attesi. Questi permettono di eseguire un singolo test per raggiungere un particolare obiettivo di test del software.
In breve, un caso di test è un’unità di test per un compito specifico.
Che cos’è uno scenario di test?
Uno scenario di test è un insieme di più casi di test.
Nell’ambito della descrizione di un determinato compito, “Come testare” è una delle sezioni più importanti, poiché aiuta lo sviluppatore a comprendere il compito.
- aiuta lo sviluppatore a comprendere il compito
- serve come riferimento rapido per l’intero processo di QA.
Come preparare una lista di controllo UAT
La lista di controllo per i test di accettazione utente (UAT) è un documento che i QA assemblano per guidare la pianificazione e l’esecuzione dei test UAT. L’obiettivo è quello di raccogliere l’intero ambito del progetto in un unico documento, composto da caratteristiche testabili del progetto.
Cosa deve includere la lista di controllo UAT?
- Funzionalità di livello aziendale rivolte al cliente, ad es:
- “L’utente può iscriversi alla newsletter”.
- “C’è un input di ricerca nell’intestazione che si espande al clic e mostra suggerimenti dopo che l’utente ha iniziato a digitare”.
- “Il layout della home page corrisponde ai design confermati”.
- Dispositivi e browser che li supportano
Come utilizzare la lista di controllo UAT?
Esaminate tutte le funzioni dell’elenco. Se la funzione si comporta come previsto, contrassegnarla come FATTO. In caso contrario, preparate un rapporto sui difetti, aspettate che vengano risolti, quindi ripetete il test. Ripetete il processo fino a quando tutte le funzionalità sono contrassegnate come FATTE.
Una volta spuntate tutte le caratteristiche dell’elenco, il documento può essere presentato al cliente come prova della qualità dell’ambito. Al di là di questo punto, spetta al cliente decidere se far testare nuovamente determinate caratteristiche.
A questo punto, il progetto può essere considerato consegnato e pronto per il Go-Live.
Tempi di compilazione della lista di controllo UAT
La lista di controllo può essere creata già a metà progetto e popolata gradualmente man mano che il lavoro procede. Una buona pratica consiste nel finalizzare la struttura della lista di controllo per almeno il 90% circa 4-6 settimane prima della consegna del progetto.
Ogni voce dell’elenco deve essere contrassegnata come FATTO quando il progetto viene presentato al cliente per la revisione.
Strategia di test per i contenuti mancanti
È estremamente importante che i contenuti del sito web siano controllati e aggiornati. Purtroppo, troppo spesso questo aspetto viene trascurato quando ci si concentra sullo sviluppo di caratteristiche e funzionalità.
Suggeriamo di creare un elenco TO-DO dei contenuti mancanti per aiutare il tester QA a identificare e tenere traccia degli elementi del progetto in cui i contenuti mancano o devono essere aggiornati. Questo documento è utile anche per comunicare queste informazioni agli altri membri del team.
Di seguito sono riportati alcuni esempi di ciò che dovrebbe e non dovrebbe essere incluso nell’elenco TO-DO dei contenuti mancanti.
- Contenuti di esempio: SÌ
- Valori di filtro non codificati: SÌ
- Informazioni identiche (segnaposto, descrizioni, ecc.) nelle versioni internazionali del sito: SÌ
- Il cliente si sta preparando a lanciare una campagna per il Black Friday, ma i banner sono per il Back To School: SÌ
- Manca una navigazione a livelli sul PLP che non è stata trasferita dal modello di design: NO, ma dovrebbe essere aggiunto all’elenco dei bug.
- Filtri mancanti nell’overlay di ricerca: NO, anche questo è un bug – una funzionalità mancante, non un contenuto mancante.
Scopo
Lo scopo è fornire un elenco aggiornato degli elementi dell’interfaccia utente con i contenuti attualmente mancanti. Di seguito sono elencati alcuni componenti da tenere d’occhio durante il test QA di un sito di commercio elettronico:
- Immagini di scorrimento
- Articoli più venduti
- Testi promozionali
- FAQ
- Pagine “Chi siamo
- Qualsiasi altra area temporaneamente riempita con “Lorem Ipsum”, contenuti di esempio o contenuti non tradotti.
Ricordate che questo documento si chiama elenco di cose da fare per un motivo preciso. Pertanto, assicuratevi di mantenerlo aggiornato aggiungendo regolarmente i problemi attuali e spuntando le voci che sono state risolte.
Motivazione
Non siete ancora convinti che sia una parte importante della strategia di test QA? Mettiamo le cose in prospettiva. Molti grandi progetti vengono ritardati perché la creazione di contenuti è considerata un compito “facile”, viene messa in secondo piano e rimandata “a dopo”. Tuttavia, oltre a essere un processo che richiede tempo, la creazione di contenuti deve spesso passare attraverso diversi livelli di convalida da parte di vari team.
In generale, non è raro che la creazione e la validazione dei contenuti richiedano più o meno lo stesso tempo dello sviluppo del progetto.
Volete portare il vostro sito web a nuovi livelli con una garanzia di qualità di livello professionale? Lasciatevi aiutare da MagentoFactory! Non esitate a contattarci per vedere come possiamo aiutare la vostra crescita aziendale.
