Come Creare un Modello di Tracciamento dei Bug in Jira
Un template di bug tracking è un formato predefinito per documentare e riportare i bug nello sviluppo software. Disporre di un template assicura che i dettagli cruciali vengano sempre raccolti con coerenza, permettendo così il tracciamento, la prioritizzazione e la comunicazione dei bug in modo più semplice all'interno del team.
Jira è uno strumento di tracciamento delle issue di Atlassian, ed è probabilmente uno degli strumenti di bug tracking più utilizzati per la gestione dei progetti di sviluppo (specialmente in ambienti agili). L'ho usato in molti progetti negli ultimi anni, sia con Scrum che con Kanban, e lo trovo molto versatile.
In questo articolo, analizzerò la versatilità di Jira nel tracciamento dei bug, nella personalizzazione e gestione dei flussi di lavoro e nel migliorare la segnalazione dei bug con Jira.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Che tu sia responsabile della configurazione dei workflow di Jira o che segnali difetti tramite esso, non fa mai male sapere come funziona. Jira è molto più di un semplice strumento di segnalazione dei bug, ma in questo articolo ci concentreremo soprattutto sul tracciamento dei bug piuttosto che sulla gestione di altri tipi di issue.
Configurare un Nuovo Progetto con Jira Software
Se il tuo progetto è nuovo, la prima cosa da fare è configurare il progetto in Jira. Di solito questo compito è affidato allo scrum master o al project manager, ma se il tuo ruolo di QA si sovrappone con uno di questi, potresti occupartene tu. Non è complicato, e comunque dovrebbe essere una cosa da fare una sola volta!
L’iscrizione è gratuita, e per progetti piccoli con meno di dieci utenti puoi utilizzare il piano gratuito. Se hai un team più grande o necessiti di funzionalità avanzate, puoi optare per uno dei piani a pagamento. Non entrerò nei dettagli, ma puoi consultare la pagina dei prezzi di Jira se sei interessato.
Ho creato nuovi progetti solo per insegnare in aula, ma il processo è abbastanza intuitivo. Avrai la possibilità di scegliere tra diversi tipi di progetti per lo sviluppo software:
Tipologie di Progetto
- Un progetto Kanban consente di creare bacheche Kanban. Puoi usare il template classico con le fasi classiche: Da fare, In corso e Completato.
- Scrum – Questo template permette al team di gestire sprint e backlog seguendo il framework Scrum.
- Bug tracking – Un template semplice che consente di tracciare le issue senza utilizzare alcuna metodologia agile.
Tutti i progetti possono essere personalizzati includendo le fasi, le transizioni e gli stati necessari al progetto.
Per questo tutorial, userò il template di progetto Scrum così puoi tracciare sia le storie che i bug nello stesso progetto, ma non preoccuparti: tutto ciò che mostrerò si può applicare anche agli altri tipi di progetto!
Tipologie di Issue
Le tipologie di issue predefinite fornite da Jira sono:
- Epic: Nell'approccio agile, un epic è una raccolta di alto livello di user story e attività.
- Bug: Il tipo di issue che utilizziamo in Jira per tracciare i bug e i difetti riscontrati. Nei prossimi paragrafi ci concentreremo su questi.
- Story: Una user story agile (descrizione della caratteristica o funzionalità da sviluppare e testare).
- Task: Di solito serve per tracciare singole attività o to-do, ad esempio la ricerca di un nuovo strumento di test automation oppure l’aggiornamento della documentazione.
- Subtask: Questo è un singolo compito assegnato a un membro del team ed è un'issue figlia della tipologia “Task” menzionata sopra.
Come già accennato, Jira è molto versatile e, se necessario, puoi creare la tua tipologia di issue in qualsiasi momento all’interno del progetto.
Ad esempio, ho lavorato a un progetto in cui avevamo una tipologia di issue separata per i miglioramenti. Queste erano simili alle user story, ma legate soprattutto a potenziamenti di funzionalità già esistenti nell’applicazione.
Oppure puoi creare un tipo di issue per i casi di test, ma ne parleremo un po' più avanti, quando tratteremo i plugin disponibili e gli strumenti di integrazione con Jira.
Gestione dei Bug con Jira
Passiamo a ciò che ci interessa come tester: la segnalazione e la gestione dei bug. Sebbene Jira sia uno strumento di gestione dei progetti e non specificatamente un bug tracker, noi QA probabilmente lo useremo molto per segnalare bug 😁.
Workflow e Ciclo di Vita del Bug
Il workflow predefinito per i bug (e per tutti gli issue, in realtà) fornito da Jira è il seguente:
Quando viene aperto un issue, viene creato con lo stato 'Da fare'. Successivamente, l'issue o bug può essere spostato in uno qualsiasi degli altri stati.
Il team di test management, lo scrum master o il project manager sono solitamente responsabili della progettazione di eventuali workflow personalizzati.
Il workflow riflette il ciclo di vita del bug che si desidera avere nel progetto. Puoi mantenere quello predefinito, più semplice, oppure renderlo complesso quanto necessario. Onestamente non ho mai lavorato su un progetto che non avesse i propri stati e transizioni personalizzati.
Per personalizzare il ciclo di vita, devi andare nelle impostazioni del progetto, selezionare il tipo di issue "bug" e cliccare su 'Modifica workflow'.
Qui puoi aggiungere qualsiasi nuovo stato e scegliere una transizione specifica, se necessario. Ecco un esempio:
In questo caso, quando viene creato un nuovo issue, avrà lo stato 'Da fare', dal quale potrà essere spostato solo a 'In corso'. Prima di poter testare il bug, il codice deve essere revisionato. Il team QA può chiuderlo una volta validato nello stato 'In QA'. Ovviamente, la revisione del codice e il processo QA possono fallire e, in tal caso, il bug verrà spostato di nuovo a 'In corso'.
Creazione Guidata del Workflow
Elenco tutti gli step necessari per passare dal primo workflow al secondo (o a qualsiasi workflow personalizzato che ritieni adatto al tuo progetto):
1. Per prima cosa, clicca sul pulsante 'Modifica workflow'
2. Per aggiungere un nuovo stato, clicca su uno degli stati — gli stati sono divisi in tre categorie: 'Da fare', 'In corso' e 'Fatto', ognuno con un colore specifico. Puoi scegliere dove inserire al meglio il tuo stato. Io ho deciso che gli stati 'In code review' e 'In QA' significano che l'issue è ancora in corso:
Puoi anche avere altri stati 'Da fare'; ad esempio uno stato 'In review' per quando viene aperta una nuova funzionalità e il product owner o business analyst deve ancora aggiungere informazioni oppure il team deve ancora raffinarla e valutarne la complessità o stimare gli story point.
3. Una volta aggiunto il nuovo stato, puoi aggiungere una transizione. Di default, lo stato può essere aggiornato da qualsiasi altro stato. Se non vuoi regole di transizione specifiche, va bene. Tuttavia, un buon workflow dovrebbe permettere che bug e issue vengano spostati in specifici stati solo dopo che abbiano attraversato determinati step del processo.
Nell’esempio sopra, il team QA non può iniziare a verificare la correzione prima che un altro sviluppatore abbia revisionato il codice. Per aggiungere questa transizione, clicca sul pulsante 'Transizione' e inserisci i dettagli:
4. Puoi anche eliminare tutte le transizioni e gli stati esistenti se desideri che tutto sia 100% personalizzato.
5. Una funzione molto utile è quella degli assegnatari automatici. Questa funzione si trova sempre nel workflow, dove puoi impostare un utente assegnato di default quando viene eseguita una determinata transizione sull'issue (ed è anche un'importante caratteristica dei software di tracciamento delle issue).
Ad esempio, dopo che un bug è stato 'Revisionato' e spostato in 'In QA', viene automaticamente assegnato a un determinato tester o al responsabile dei test che deciderà chi se ne occuperà. Lo stesso vale per 'In Progress' e il team di sviluppo. I problemi appena creati possono essere assegnati automaticamente a un project manager o a un product owner, che si occuperà poi di priorizzarli nel backlog. Il sistema è altamente personalizzabile, così puoi adattarlo alle esigenze specifiche del tuo team.
Anche se non sei responsabile dell'impostazione dei cicli di vita dei problemi, o se non hai accesso alle impostazioni del progetto, puoi visualizzare il workflow di ogni issue Jira espandendo il menu a tendina dello stato:
Visualizzazione delle issue in Jira
Se il progetto non è un progetto di tracking dei bug, puoi visualizzare le issue correnti nelle board Kanban o Scrum:
Questo è solo a scopo dimostrativo; dubito che sarai mai così fortunato da avere uno sprint con solo una user story e un bug 😅.
Cliccando su qualsiasi issue verranno mostrati i relativi dettagli. Tra questi ci sono, ma non solo, un ID (che viene creato automaticamente da Jira), un titolo, una descrizione, il segnalatore, l'assegnato e tutti gli allegati o commenti aggiunti dai membri del team.
I campi sono personalizzabili e te lo mostrerò quando parleremo di cosa dovrebbe contenere una buona segnalazione di bug.
Assegnatari
Tutte le issue Jira possono essere assegnate a un membro specifico del team. Puoi menzionare le persone nei commenti o nella descrizione usando il carattere @ prima del nome dell'utente.
Riceverai notifiche quando qualcuno ti menziona e quando un'issue assegnata a te o inserita da te viene aggiornata. Puoi anche "seguire" le issue. Riceverai notifiche sugli aggiornamenti delle issue seguite indipendentemente da chi sia il segnalatore o l'assegnatario.
Segnalazione dei bug in Jira
Avere un'applicazione con pochi bug è l'obiettivo di tutti, ma diciamocelo: i tester sono sempre contenti quando troviamo un buon bug.
Ma un buon bug è tale solo se viene ben descritto—un buon report permetterà la sua correzione con il minor numero possibile di passaggi tra il team di testing e quello di sviluppo. Jira è un ottimo strumento per la gestione dei bug. L'ho già detto? Offre molta flessibilità.
Per creare una nuova issue, clicca sul grande pulsante 'Crea' e si aprirà una finestra di dialogo. Qui, seleziona il tipo di issue 'Bug':
Un buon report deve includere una buona descrizione (o 'Sommario' in Jira). Deve essere conciso ma con abbastanza dettagli perché sia chiaro di cosa si tratta.
Poi, nella descrizione, aggiungi tutti i dettagli rilevanti. Puoi strutturarli nel modo classico:
- Passaggi per riprodurre il bug
- Risultato atteso
- Risultato effettivo
Successivamente, inserisci qualsiasi altro dettaglio rilevante per il difetto. Screenshot o registrazioni sono sempre utili, così come i log o file specifici utilizzati durante il test.
Jira permette di aggiungere campi personalizzati alle issue. A me piace separare la 'Severità' dalla 'Priorità'. Quindi, mentre 'Priorità' è un campo di default di Jira, puoi aggiungerne uno personalizzato per la 'Severità'.
Altri campi personalizzati utili possono riguardare il sistema operativo—un campo testo o una tendina con valori predefiniti, come le versioni di Android e iOS usate nel test, il browser, il numero di build o qualsiasi altra informazione che possa essere utile per tracciare i bug.
Per aggiungere nuovi campi, vai nelle impostazioni del progetto, seleziona il tipo 'Bug' e scegli che tipo di campo vuoi aggiungere:
Casi di test in Jira
L'ultima cosa di cui voglio parlare sono i casi di test. Il software Jira può essere integrato con vari strumenti di gestione dei test oppure puoi aggiungere estensioni e componenti aggiuntivi di Atlassian, come Zephyr (che era il mio preferito) o Xray. Quando crei un bug come risultato di un caso di test fallito, il test può essere collegato al bug, il che può essere molto utile nella gestione di bug, test ed esecuzione dei casi di test.
Vuoi di più?
Jira può essere un ottimo strumento di tracciamento dei difetti e può migliorare il processo di sviluppo perché permette molta personalizzazione. Quando si tratta di bug, è davvero utile perché puoi personalizzare il flusso di lavoro in base al ciclo di vita che desideri avere nel tuo progetto. Puoi collegare i bug ai casi di test e aggiungere campi personalizzati nel modo che ha più senso per il tuo progetto specifico.
Per altre guide pratiche come questa, iscriviti alla newsletter di The QA Lead.
