La bug review
Introduzione
La bug review, o triage dei bug, è il lavoro più impegnativo del Tester Leader e consiste nel verificare la correttezza dei bug segnalati dai tester, per poi fornirne una valutazione finale. Se non ricordi come arrivare alla pagina dei bug o quale essa sia, prima di procedere leggi questa guida.
Un riassunto delle seguenti regole, valido per la scrittura da parte dei tester (ma non completo per il lavoro che svolge il TL) può essere trovato in queste pagine, che possono essere condivise coi tester:
- https://crowd.app-quality.com/it/regole-di-scrittura-dei-bug/ (versione italiana)
- https://crowd.app-quality.com/bug-reporting-rules-2/ (versione inglese)
In questa guida viene trattata la fase di "review" di un bug nell'ottica della sua scrittura e presentazione dei contenuti, mentre tutto l'aspetto "valutativo" è demandato a quest'altra guida, mentre qui si può trovare la pagina di bug review.
Riassunto degli elementi da verificare in una segnalazione
I campi di un bug sono riassumibili nel modo seguente:
- titolo (riassume la problematica e la sezione in cui si trova in modo breve ma esaustivo)
- descrizione (indica, in passi numerati da 1 a X, un accapo all'altro, come giungere al problema, senza però descrivere il problema stesso)
- risultato atteso (il comportamento atteso dal prodotto, che non si è verificato)
- risultato effettivo (il comportamento imprevisto verificatosi nel prodotto)
- commenti aggiuntivi (per indicare elementi e dettagli che non rientrano negli altri campi)
- campi addizionali (dettagli aggiuntivi che non rientrano negli altri campi)
- media (almeno 1 screenshot e 1 video, o solo 2 screenshot nei casi di bug banali)
Ogni bug richiede tipicamente il caricamento di almeno 2 media che provino la presenza del bug stesso. I media supportano la segnalazione, ma senza di essi il bug deve essere ugualmente comprensibile. Nonostante non ci siano dei limiti formali nell'upload di specifiche tipologie di media, è bene che ogni bug abbia sempre almeno 1 video e 1 screenshot (ad eccezione dei bug più banali, come i bug di scrittura e i bug grafici, dove 2 screenshot sono spesso sufficienti). Il video deve essere sufficientemente lungo da mostrare i passi eseguiti e il problema che si verifica.
Preparazione alla review di un bug
Prima di effettuare la review di un qualsiasi bug, è sempre necessario che il Tester Leader abbia letto attentamente il manuale di Test, inclusi eventuali sezioni o comportamenti/bug specificati come Out Of Scope (non oggetto del test). Qualora prima della review, o durante essa, pervenissero dei dubbi sullo scope di test, è bene chiarirli con il CSM prima di procedere con la review.
La review di un bug
La lingua dei bug
Regole generali
I bug devono essere scritti tutti nella stessa lingua e in italiano nella maggior parte delle attività e ove non specificato diversamente. In presenza di test di localizzazione (verifica della corretta traduzioni di frasi in siti esteri) è buona prassi indicare ai tester di riportare eventuali frasi, passi, nomi di bottoni o azioni che siano in lingua straniera, anche in inglese, così che il revisore dei bug possa capire al meglio le problematiche.
Il Campo "Titolo"
Regole generali
Il titolo deve presentare la sezione o il processo in cui il problema si verifica inscritto tra parentesi quadre (non il nome o il numero dello use case), seguito da un riassunto breve e comprensibile del problema, in modo che possa essere compreso e distinto chiaramente da chiunque, anche da chi non conosce il test o il prodotto.
La review di un bug inizia sempre dal campo titolo, attraverso il quale si deve sempre poter capire in cosa consista il problema. Il titolo deve sintetizzare la problematica e il punto del prodotto da testare in cui la problematica si trova.
Se non esplicitato diversamente, il titolo deve avere formato [Sezione] - Titolo. La sezione NON è il nome del caso d'uso o del passo eseguito, bensì è il nome dell'area o del processo in cui si è identificato il problema. Durante la scrittura del titolo, è obbligatorio mantenere il formato indicato, compresi gli spazi prima e dopo il trattino. E' buona normale che la sezione inizi con lettera maiuscola, così come anche il titolo, mentre tutto il resto del testo è bene che sia scritto in minuscolo, ove sensato.Confronto|testo_ko=[USE CASE 1] – L’accesso non funziona
[Home] – Errore
[App] - Non funziona|testo_ok=[Login] – Impossibile effettuare l’accesso usando credenziali corrette
[Checkout] - Il checkout con Paypal non viene completato correttamente
[Ricerca] - I risultati mostrati non sono coerenti con quanto cercato Policy di correzione
Gran parte dei titoli dei bug non sono corretti o sono imprecisi, quindi il TL può alternativamente:
- correggere il titolo manualmente
- richiedere al tester di correggere il titolo indicandogli il formato corretto (questa seconda opzione è consigliata in quanto permette al tester di migliorarsi)
Si noti che il cliente spesso valuta la qualità del lavoro eseguito anche solo dai titoli, lasciando agli sviluppatori poi verificare i dettagli dei bug. Risulta quindi di fondamentale importanza che non siano presenti titoli troppo lunghi, corti o con errori di scrittura.
Infine, la scelta di un buon titolo facilita di molto il lavoro del TL, che potrà marcare più facilmente i bug duplicati (se ne parlerà meglio più avanti).
Errori più comuni
- il titolo ha come sezione il numero o il nome del caso d'uso
- il titolo è lunghissimo
- il titolo ha solo una parola come sezione e solo una parola come titolo
- il titolo ha errori di scrittura, è scritto in diversa lingua, riguarda un bug diverso dall'attuale o non è comprensibile
I selettori di Severità, Categoria e Replicabilità
Regole generali
La severità è una stima dell’impatto del problema sull’utilizzo del prodotto, scelta tenendo conto del contesto in cui si verifica (sezioni primaria o secondaria rispetto al core-business dell'oggetto del test), tenendo anche conto delle condizioni in cui è stato riscontrato rispetto ad un utilizzo medio. La valutazione della replicabilità non deve in alcun modo influenzare la severity: infatti guidano nella scelta prevalentemente l’impatto sull'utente, il contesto (importanza della sezione) e la presenza o meno di un work-around.
| Severity | Descrizione |
|---|---|
| LOW | Problemi che hanno un impatto minimo nell’utilizzo del prodotto, di fronte ai quali l'utente è sempre e comunque in grado di continuare ad utilizzare l'oggetto di test senza rimanerne particolarmente turbato. Spesso si tratta di bug di tipologia USABILITY, TYPO o GRAPHIC. |
| MEDIUM | Problemi che hanno un impatto contenuto nell'utilizzo del prodotto, davanti ai quali l’utente riesce comunque a completare il processo rimanendone solo parzialmente turbato. Può trattarsi di ogni tipologia di bug. |
| HIGH | Problemi che hanno un impatto significativo nell’utilizzo del prodotto ed accadono prevalentemente nelle sezioni principali, davanti ai quali l’utente potrebbe non essere in grado di continuare ad utilizzare l'oggetto di test nel modo previsto e/o ne rimarrebbe turbato e limitato. Generalmente si tratta di bug di tipologia MALFUNCTION, CRASH, PERFORMANCE o SECURITY. |
| CRITICAL | Problemi che impediscono il completamento delle azioni strettamente principali, spesso comportando un blocco del sistema. L'utente non è in alcun modo in grado di continuare ad utilizzare l'oggetto di test come desidera. Si tratta prevalentemente di bug di tipologia MALFUNCTION o CRASH. |
La categoria definisce la tipologia percepita del bug, in base alla sensibilità e all'esperienza tecnologica del Tester Leader è possibile indicare la tipologia percepita immediatamente o quella potenzialmente legala alla root cause del problema.
| Type | Descrizione |
|---|---|
| Crash | Problemi che comportano la chiusura o non responsività del prodotto, per i quali l'utente è costretto a riavviarlo per continuare ad utilizzarlo, ad esempio applicazione che si chiude, caricamenti infiniti, pagine 404. |
| Graphic | Problemi legati alla sfera estetica del prodotto, quali sovrapposizioni di elementi generici, contrasti errati, incoerenza tra elementi simili in uno stesso contesto, testi o immagini tagliati, sfocati, fuori schermo, parzialmente non visibili o sovrapposti. |
| Performance | Problemi strettamente legati alla velocità di caricamento dei contenuti o nel completamento dei processi del prodotto di test (lag, rallentamenti, ritardi). Se questo caricamento eccessivo non si conclude mai (loop), allora il problema è riconducibile a un CRASH. |
| Malfunction | Problemi relativi al mancato o errato funzionamento di una feature presente all'interno del prodotto. Nel caso in cui il funzionamento sia generalmente corretto ma diverso dalle aspettative dell'utente, allora il problema è riconducibile a USABILITY. |
| Typo | Problemi legati ad errori grammaticali, ortografici, semantici, lessicali o sintattici, traduzioni errate o incomplete, frasi incomplete (non graficamente tagliate) o prive di senso, codice in vista o non comprensibile. |
| Altro | Tutti i problemi che non appartengono alle altre categorie. |
| Security | Problemi unicamente legati alla sicurezza e al mantenimento della riservatezza dei dati salvati. Si includono sezioni con password in chiaro, mancata scadenza dei login o anche libera possibilità di ottenimento di dati di altri utenti tramite SQL injection o attacchi XSS. |
| Usability | Problemi legati all’utilizzo del prodotto, che rendono all'utente difficile svolgere una certa azione o compito a causa di percorsi lunghi, complessi, non ideali o poco intuitivi. Si includono i casi in cui il funzionamento differisca completamente dalle aspettative dell'utente. Rientrano anche l'assenza di controlli sull'inserimento di dati nei campi ed i problemi legati a messaggi di errore con testo non contestualizzato rispetto al reale problema presente (errore generico). |
| Replicability | Descrizione |
|---|---|
| Sometimes | Il bug si verifica, a parità di condizioni e processi, in modo sporadico/imprevedibile, ma è sempre possibile riprodurlo eseguendo più tentativi. |
| Always | Il bug si verifica, a parità di condizioni e processi, ad ogni tentativo di replica. Per essere tale, il bug deve essere riprodotto con successo almeno 3 volte su 3. |
| Once | Il bug si è verificato soltanto una volta e non è stato possibile riprodurlo ulteriormente nonostante sia stato replicato almeno 3 volte. |
Policy di correzione
Spesso, tutte e 3 le caratteristiche sopra descritte sono errate, quindi si può:
- correggere le caratteristiche manualmente (consigliato)
- richiedere al tester di correggere le caratteristiche spiegandone il motivo (questa seconda opzione è consigliata in quanto permette al tester di migliorarsi, ma può essere onerosa in termini di tempo durante la review)
Si noti che il tester tende molto spesso a sopravvalutare la severità del bug, sia perchè questa è legata al pagamento, sia perchè come utilizzatore continuativo del prodotto oggetto del test ogni problema spesso può risultare "più grave di quanto potrebbe essere per un utilizzatore sporadico o comune".
Errori più comuni
- la severità è di un grado più alto di quello reale
- la tipologia graphic è confusa con typo
- la tipologia malfunction è confusa con crash o con performance
- la tipologia other è usata in casi non idonei, che rientrerebbero in altre categorie già presenti
Il Campo "Descrizione"
Regole generali
La descrizione del bug deve presentare un elenco puntato di azioni da effettuare per poter replicare il percorso che ha portato al problema, senza però indicare il problema stesso. Dunque la descrizione deve sempre fermarsi immediatamente prima dell'avvenimento del bug. Ogni singolo passaggio deve essere riportato in un passo (preceduto dal suo numero) in modo chiaro, identificando univocamente il comportamento dell’utente sul prodotto (ad es. tap, click, indietro sullo smartphone o sul browser) e le scelte effettuate o i tasti cliccati (i nomi delle sezioni o dei bottoni devono essere scritti tra virgolette). Inoltre, eventuali precondizioni vanno esplicitate sempre nei primi punti.
Durante la review, si deve ricordare che alcuni caratteri (come ">" e "&") vanno riscritti, in quanto appaiono come "&" o simili. Confronto|testo_ko=1. Aprire l’App;
-
Login;
-
Caricamento.|testo_ok=1. Aprire l’app appena installata e atterrare sulla pagina di login;
-
Compilare i campi con una credenziale corretta;
-
Cliccare sul bottone “Effettua l’accesso”. Policy di correzione
Se la descrizione di un bug non è corretta o è imprecisa, il TL può alternativamente:
- correggere la descrizione manualmente
- richiedere al tester di correggere la descrizione indicandogli il formato corretto (questa seconda opzione è consigliata quando la descrizione è del tutto incomprensibile, così da non rendere attuabile una correzione manuale)
Errori più comuni
- la descrizione è tutta su una riga
- la descrizione ha come ultimo punto una descrizione del bug che si è verificato
- mancano i punti progressivi (1. 2. 3.) prima di ogni passo o i numeri non sono consecutivi
Il Campo "Risultato Atteso"
Regole generali Il risultato atteso deve descrivere esclusivamente quello che sarebbe dovuto essere il comportamento del prodotto da testare, che invece non si è realizzato, riferendosi sempre al contesto in cui il bug si è verificato. Confronto|testo_ko=Area riservata|testo_ok=L’utente dovrebbe visualizzare l’area riservata agli utenti che hanno effettuato il login. Policy di correzione
Se il risultato atteso di un bug non è corretto o è impreciso, il TL può alternativamente:
- correggere il risultato atteso manualmente
- richiedere al tester di correggere il risultato atteso (questa seconda opzione è consigliata quando il risultato atteso è del tutto incomprensibile, così da non rendere attuabile una correzione manuale)
Errori più comuni
- il risultato atteso si dilunga in dettagli che non servono
- il risultato atteso descrive il risultato attuale, e non quello atteso
- il risultato atteso è troppo corto o incomprensibile
Il Campo "Risultato Effettivo"
Regole generali Il risultato effettivo descrive in modo completo il comportamento del prodotto in riferimento al bug che si è verificato all’interno del suo contesto di riproducibilità. Eventuali comportamenti simili adottando procedure leggermente diverse vanno riportate in questo campo, così come vanno indicati anche eventuali dettagli sulla riproducibilità del bug. Confronto|testo_ko=Il login non avviene.|testo_ok=Visualizzazione infinita dell’icona di caricamento, senza possibilità di accesso. Anche provando con “ricorda credenziali” il problema persiste ad ogni tentativo. Policy di correzione
Se il risultato effettivo di un bug non è corretto o è impreciso, il TL può alternativamente:
- correggere il risultato atteso manualmente
- richiedere al tester di correggere il risultato atteso (consigliato se non è chiaro dagli allegati quale sia il problema)
Errori più comuni
- il il risultato effettivo si dilunga in dettagli che non servono o parla anche di altri bug
- il risultato effettivo descrive il risultato atteso, e non quello effettivo
- il risultato effettivo è troppo corto o incomprensibile
Il Campo "Commenti Addizionali"
Regole generali
I commenti aggiuntivi non sono obbligatori e sono riservati ad eventuali osservazioni generali che non dettagliano gli step ma aiutano a prendere contesto del problema. Confronto|testo_ko=Il risultato atteso è il login.|testo_ok=Il problema si verifica indipendentemente dal browser usato. Policy di correzione
Se i commenti aggiuntivi di un bug non sono corretto o sono imprecisi, il TL può alternativamente:
- correggere i commenti aggiuntivi manualmente o eliminarli
Errori più comuni
- i commenti presentano dettagli irrilevanti
- i commenti presentano messaggi rivolti al revisore che non sono utili al cliente
I Media dei Bug
Regole generali Ogni bug richiede tipicamente il caricamento di almeno 2 media che provino la presenza del bug stesso. I media supportano la segnalazione, ma senza di essi il bug deve essere ugualmente comprensibile. Nonostante non ci siano dei limiti formali nell'upload di specifiche tipologie di media, è bene che ogni bug abbia sempre almeno 1 video e 1 screenshot (ad eccezione dei bug più banali, come i bug di scrittura e i bug grafici, dove 2 screenshot sono spesso sufficienti). Il video deve essere sufficientemente lungo da mostrare i passi eseguiti e il problema che si verifica.
Possibilmente i media devono avere una chiara indicazione del problema (per esempio se si tratta di un typo, avere ben evidenziata l'area o la frase coinvolta) e presentare la visibilità dei tocchi effettuati se ciò facilita la comprensione del problema.
Policy di correzione
Se i media di un bug non sono corretti o sono imprecisi, il TL può alternativamente:
- cancellare i media indesiderati (non si può tornare indietro) e richiederne di nuovi
- chiedere nuovi media, indicando cosa non vada bene dei precedenti
- chiedere uno o più screenshot/video aggiuntivi, che possono anche non essere inerenti strettamente al bug (es. screenshot della versione dell'app, di uno speedtest o altro)
Errori più comuni
- assenza del video per crash o malfunzionamenti
- il bug non presenta il video per problemi di performance
- assenza di speedtest in bug di performance
- screenshot di aree non inerenti al bug e non richiesti
[Editable by::users](editable by/users)