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.

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.

Il ciclo di vita di un report di un Ticket/Bug si può riassumere in quattro singole fasi:

1. Segnalazione
2. Validazione Segnalazione
3. Soluzione
4. 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.

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/

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/

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.

TODO

TODO