Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.
Entrambe le parti precedenti la revisione Revisione precedente Prossima revisione | Revisione precedente | ||
faqs:howtocreateaticket [2015/10/08 12:27] admin [Introduzione] |
faqs:howtocreateaticket [2015/12/16 14:38] (versione attuale) admin [Segnalazione] |
||
---|---|---|---|
Linea 7: | Linea 7: | ||
===== Introduzione ===== | ===== Introduzione ===== | ||
- | Un ticket per la segnalazione di un bug software/richiesta di assistenza deve esser **esaustivo** e **conciso**. | + | 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**. | 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**. | ||
Linea 14: | Linea 14: | ||
===== Ciclo di vita ===== | ===== Ciclo di vita ===== | ||
- | Il ciclo di vita di un report di un bug si può riassumere in quattro singole fasi: | + | Il ciclo di vita di un report di un Ticket/Bug si può riassumere in quattro singole fasi: |
- Segnalazione | - Segnalazione | ||
- Validazione Segnalazione | - Validazione Segnalazione | ||
- | - Bugfixing | + | - Soluzione |
- | - Validazione Bugfixing | + | - 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. | 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 ==== | ==== Segnalazione ==== | ||
E' compito del //Segnalatore// fare in modo che un ticket risponda a **__tutti__** i seguenti **requisiti**: | 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. | + | * **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. | * **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. | * **Versione Software**: la versione software in cui è stata riscontrata la problematica. | ||
* **Prodotto/Brand**: il prodotto ed il brand 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. | * **Macchina Client**: i dati sulla macchina client utilizzata. | ||
- | * **Descrizione del problema**: una descrizione __sintetica__ ed __esaustiva__ del problema. | + | * **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. | * **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. | * **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. | ||
Linea 34: | Linea 34: | ||
* **Ricreare __esattamente__**, in laboratorio, l'esatta problematica. | * **Ricreare __esattamente__**, in laboratorio, l'esatta problematica. | ||
* **Comprendere** la situazione più facilmente. | * **Comprendere** la situazione più facilmente. | ||
- | * **Dimostrare** l'effettiva presenza di un bug. | + | * **Dimostrare** l'effettiva presenza di un problema. |
- | 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. | + | 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. | * **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. | ||
Linea 43: | Linea 43: | ||
* Estratto bus KNX | * 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. | + | 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. | Per qualsiasi approfondimento è sufficiente documentarsi un attimo: esistono migliaia di articoli e libri in merito. | ||
Linea 64: | Linea 64: | ||
In fase di validazione è necessario: | 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. | * **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. | + | * **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. | * **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 ==== | + | ==== Soluzione ==== |
TODO | TODO | ||
- | ==== Validazione Bugfixing ==== | + | ==== Validazione Soluzione ==== |
TODO | TODO |