La valutazione dei bug

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 valutazione, mentre tutto l'aspetto di scrittura e accettazione dei contenuti è demandato a quest'altra guida. Qui invece si può trovare la pagina di bug review.

Gli stati dei bug

Su AppQuality un bug può avere 4 stati con le caratteristiche che seguono.

PENDING

• I bug in questo stato sono tutti quelli appena caricati dai tester e che ancora non sono stati valutati
• Nessun punto viene attribuito o tolto al tester
• Il tester non ha diritto ancora ad alcun Payout per questo bug
• Alla prima valutazione, lo stato del bug potrà cambiare con uno di quelli seguenti e non potrà mai più tornare PENDING

APPROVED

• I bug in questo stato sono tutti quelli approvati
• Vengono attribuiti automaticamente dei punti
• Finchè il bug è approvato il tester a diritto ad un Payout per il bug (ove previsto)
• Lo stato del bug può comunque essere cambiato in ogni momento, anche dopo l'approvazione, in REFUSED o NEED REVIEW

NEED REVIEW

• I bug in questo stato sono tutti quelli marcati come incompleti e devono essere integrati con nuovi dati o informazioni, coerentemente con le indicazioni fornite dal TL
• Nessun punto viene attribuito o tolto al tester
• Il tester non ha diritto ancora ad alcun Payout per questo bug
• Lo stato del bug può comunque essere cambiato in ogni momento in APPROVED o REFUSED

REFUSED

• I bug in questo stato sono tutti quelli marcati come non validi
• Vengono tolti automaticamente dei punti al tester
• Il tester non ha diritto ancora ad alcun Payout per questo bug
• Lo stato del bug può comunque essere cambiato in ogni momento in APPROVED o NEED REVIEW

L'approvazione di un bug

Un bug, sia nel suo stato iniziale, che dopo una modifica, può e deve essere approvato quando può essere confrontato con una certa precisione (non per forza esatta) con le seguenti condizioni di approvazione. Se il bug si trova lontano da queste condizioni, specie su più campi, può essere modificato affinchè rispetti le condizioni di approvazione o essere messo in Need Review.

In caso di dubbi su uno o più bug, il Tester Leader può chiedere delucidazioni al CSM se queste riguardano lo scope del test o i desideri del cliente, ma è bene che questo non avvenga su un alto numero di bug nella campagna.

Titolo	Severità, tipo e replicabilità	Use-case	Descrizione	Risultato atteso	Risultato attuale	Allegati	Riassunto
Titolo in formato corretto, sintetico ma esplicativo, coerente e senza errori	Dati inseriti in modo coerente e generalmente corretti	Coincidenza con il corretto caso d'uso	Spiegazione completa, strutturata e ben argomentata	Spiegazione completa e soddisfacente del risultato desiderato	Spiegazione completa del fenomeno, senza che siano richiesti approfondimenti ai fini della comprensione del problema.	Almeno uno o più allegati sono di qualità e consentono di capire e/o riprodurre il bug con certezza. C'è almeno 1 screenshot allegato, oltre al resto dei media.	Bug ottimamente spiegato e documentato in modo tale da non richiedere ulteriori approfondimenti, se non opzionali.

La need review di un bug

Un bug che si trovi in uno stato intermedio tra la condizione di approvazione e la condizione di rifiuto, può essere modificato o messo in Need Review specificando tutti i problemi dei vari campi. Di seguito le condizioni di non approvazione, che devono far scattare una scelta tra la modifica manuale del bug o il passaggio del bug allo stato di Need Review.

In caso di dubbi su uno o più bug, il Tester Leader può chiedere delucidazioni al CSM se queste riguardano lo scope del test o i desideri del cliente, ma è bene che questo non avvenga su un alto numero di bug nella campagna.

Titolo	Severità, tipo e replicabilità	Use-case	Descrizione	Risultato atteso	Risultato attuale	Allegati	Riassunto
Formato non corretto e/o titolo che non esplica il bug, non consentendo di individuarlo o distinguerlo da altri, anche di diverso tipo	Uno o più campi non sono coerenti tra di loro, sono errati, imprecisi o ambigui.	Caso d'uso non ideale	Descrizione non in formato passo-passo o non del tutto comprensibile e/o sufficientemente dettagliata, errori di scrittura	Spiegazione parziale del risultato atteso, fin troppo simile al titolo o al risultato attuale, mancanza di argomentazione	Spiegazione parziale del fenomeno, fin troppo simile al titolo o al risultato attuale, mancanza di argomentazione	Bug minimamente comprensibile e non esattamente riproducibile, assenza di video indispensabile	Bug poco comprensibile e riproducibile, scarsa argomentazione, presenza di errori di formato/scrittura in più campi, contenuti fuorvianti

Il rifiuto di un bug

Al momento, in base alle Policy definite, il rifiuto di un bug non avviene per motivi strettamente legati alla sua qualità di scrittura ma rispetto al suoc contenuto sostanziale. Questo significa che si è titolati a rifiutare un bug quando:

• il bug era indicato chiaramente come Out Of Scope
• il bug non costituisce un bug ma una richiesta di funzionalità, non andando a rappresentare un impedimento che limita l'usabilità del prodotto per come è fatto, ma riferendosi piuttosto ad un potenziamento del prodotto
• il bug descrive un comportamento che è quello atteso [Editable by::users](editable by/users)Il rifiuto di un bug deve sempre essere motivato tramite il pannello di comunicazione della bug review, così che il tester possa esserne informato. Il tester ha sempre diritto a richiedere maggiori informazioni al Tester Leader in merito al rifiuto del bug e fornire eventualmente nuove motivazioni affinchè venga approvato.

In caso di dubbi su uno o più bug, il Tester Leader può chiedere delucidazioni al CSM se queste riguardano lo scope del test o i desideri del cliente, ma è bene che questo non avvenga su un alto numero di bug nella campagna.

Nascondere un bug al cliente

Nella pagina di bug review, si può optare per nascondere un bug dalla visibilità del cliente. Questo può avvenire, solo se in accordo col CSM, solitamente nei seguenti casi:

• il bug non era indicato chiaramente come Out Of Scope nel manuale, pur essendolo
• il bug non è Out Of Scope ma al cliente non interessa

I bug duplicati e l'indicazione di un bug come duplicato

Tutte le campagne di tipo "non bug parade" prevedono l'accettazione di bug duplicati e l'impossibilità, da parte dei tester, di vedere i bug l'un l'altro. Capita dunque spesso di effettuare la review di una serie di bug che erano stato già approvati in precedenza: questi bug vengono definiti duplicati.

Quando si individua un duplicato, questo deve essere associato tramite l'apposito campo di selezione al proprio "padre" (ovvero il bug, definito come "padre" o "unico", approvato in precedenza). E' bene che il padre di ogni gruppo di bug sia il migliore di tutti, tuttavia a volte questo può essere oneroso, quindi è accettabile anche che il bug "padre" sia un sub-ottimo tra tutti i bug che trattano lo stesso problema.

La cosa più importante è non fare arrivare al cliente numerosi bug duplicati non segnalati o riconosciuti come tali.