DOMOTICA LABS WIKI

Questa pagina è in sola lettura. Puoi visualizzare il sorgente, ma non puoi modificarlo. Contatta l'amministratore se pensi che ci sia un errore.
====== 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 bug software/richiesta di assistenza 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 bug si può riassumere in quattro singole fasi:
  - Segnalazione
  - Validazione Segnalazione
  - Bugfixing
  - Validazione Bugfixing
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 bug; più 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.
  * **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 bug.
  Ad esempio il report di un bug 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 di un bug, 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 bug 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 bug è 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 bugfixing.
  * **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.

==== Bugfixing ====
TODO


==== Validazione Bugfixing ====
TODO
DOMOTICA LABS WIKI

Strumenti Utente

Strumenti Sito

Strumenti Pagina
