====== Come creare un Ticket/Bug Report ( v1.0.1 )====== Scopo di questa pagina è descrivere come generare una segnalazione di un bug software corretta. Nel tempo la pagina si evolverà includendo eventuali nuovi esigenze e modifiche. ---- ===== Introduzione ===== Un ticket per la segnalazione di un Ticket/Bug deve esser **esaustivo** e **conciso**. Chiunque, con una conoscenza di base del prodotto/software, deve esser in grado di **comprendere** la problematica segnalata e di riprodura **nel più breve tempo possibile**. ---- ===== Ciclo di vita ===== Il ciclo di vita di un report di un Ticket/Bug si può riassumere in quattro singole fasi: - Segnalazione - Validazione Segnalazione - Soluzione - Validazione Soluzione In realtà il ciclo di vita di un sistema di ticketing è molto più complesso ma, per le nostre esigenze attuali, la situazione descritta di seguito è più che sufficiente. ==== Segnalazione ==== E' compito del //Segnalatore// fare in modo che un ticket risponda a **__tutti__** i seguenti **requisiti**: * **Una singola segnalazione per ogni report**: Ogni singola segnalazione deve contenere lil report di un solo Ticket/Bug; più Ticket/Bug devono quindi esser descritti su più report. **N.B.** Se nell'evolversi del software il comportamento della segnalazione muta drasticamente, __deve__ nascere un nuovo report ad indicare la nuova situazione e deve esser eventualmente relazionato o chiuso quello precedente. * **Titolo chiaro**: il titolo del report deve esser essenziale e permettere, il più possibile, di cogliere al volo la problematica segnalata. * **Versione Software**: la versione software in cui è stata riscontrata la problematica. * **Prodotto/Brand**: il prodotto ed il brand in cui è stata riscontrata la problematica. * **Macchina Client**: i dati sulla macchina client utilizzata. * **Descrizione del problema**: una descrizione __sintetica__ ed __esaustiva__ del problema; se possibile, aggiungere anche dopo quale evento abbia preceduto la comparsa del problema. * **Passi per riprodurre il problema**: una descrizione degli __esatti passi__ da compiere, utilizzando il materiale allegato, per riprodurre il problema su una macchina differente con le stesse componenti Hardware/Software. * **Risultati attesi/Risultati ottenuti**: una descrizione dei __risultati ottenuti__ e dei __risultati attesi__; da intendersi nel modo più generale possibile. Ad esempio, se ci si attende un particolare stile grafico bisogna sia indicare lo stile grafico che si sta vedendo in questo momento e che si considera errato, sia lo stile grafico atteso. * **Allegati per riprodurre il problema**: il report deve esser accompagnato da una serie di allegati che permettono di: * **Ricreare __esattamente__**, in laboratorio, l'esatta problematica. * **Comprendere** la situazione più facilmente. * **Dimostrare** l'effettiva presenza di un problema. Ad esempio il report deve esser sempre accompagnato dall'esportazione del DB per __ricreare__ l'esatta situazione in cui è stato creato, può esser accompagnato da uno screenshot per facilitare la __comprensione__ di una particolare schermata e può esser accompagnato dall'estratto del bus KNX per __dimostrare__ l'assenza di alcuni tracciamenti su iKon. * **Commentare** significa aggiungere dettagli o chiedere chiarimenti. Utilizzare i commenti per cambiare continuamente la descrizione originale della segnalazione crea confusione. **N.B.** Comportamenti differenti dalla descrizione della segnalazione implicano la creazione di nuove segnalazioni, eventualmente relazionate tra loro. Ecco una lista consigliata di allegati utili da aggiungere alle segnalazioni: * DB esportato del progetto ( .dpadDB ) * Estratto tab Newtork di Chrome ( .HAR ) * Estratto bus KNX Chiaramente, non è possibile descrivere ogni possibile casistica; pertanto ci si affida alle capacità e alla sensibilità del Segnalatore nel descrivere nel migliore dei modi il report, seguendo queste linee guida. Per qualsiasi approfondimento è sufficiente documentarsi un attimo: esistono migliaia di articoli e libri in merito. Ecco qualche esempio: * http://www.chiark.greenend.org.uk/~sgtatham/bugs.html * http://noverse.com/blog/2012/06/how-to-write-a-good-bug-report/ === Estratto Network di Chrome ( .HAR ) === E' buona regola effettuare il test con lo strumento di analisi di rete aperto, offerto da Chrome. Per usarlo è sufficiente premere, CTRL+Shift+I avviando gli strumenti di sviluppo, e poi selezionando il tab "Nerwork" In caso di problemi, premendo il tasto destro del mouse sulla lista, è possibile salvare un estratto .HAR. Il file estratto può esser gestito utilizzando diversi tool come: * http://www.softwareishard.com/har/viewer/ * http://ericduran.github.io/chromeHAR/ ==== Validazione Segnalazione ==== E' compito del //Validatore// rivedere tutti i report segnalati dal //Segnalatore//. In fase di validazione è necessario: * **Controllare il report**: la segnalazione deve rispondere ai requisiti in modo esaustivo; in caso contrario è necessario richiedere al Segnalatore di correggere, aggiungere o confermare eventuali cambiamenti. * **Validare la presenza del problema nella versione software desiderata**: è necessario ripercorrere la segnalazione e controllare che, nella versione del software da correggere, il baco sia realmente presente nelle modalità descritte dal //Segnalatore//. L'operazione di validazione della presenza del problema è necessaria perchè permette non solo di confermare la presenza del problema ma anche di comprendere se il report contiene realmente tutti i dati necessari per esser replicato in fase di "Soluzione". * **Girare il ticket**: a validazione completata, se l'operazione ha avuto esito positivo in tutti i suoi aspetti, il //Validatore// gira il ticket allo //Sviluppatore//; in caso contrario lo indirizza al //Segnalatore// per chiedere ulteriori dettagli o conferme. ==== Soluzione ==== TODO ==== Validazione Soluzione ==== TODO