Strumenti Utente
faqs:howtocreateaticket
Differenze
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 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 | ||
faqs/howtocreateaticket.1444300079.txt.gz · Ultima modifica: 2015/10/08 12:27 da admin
Ad eccezione da dove è diversamente indicato, il contenuto di questo wiki è soggetto alla seguente licenza: CC Attribution-Share Alike 4.0 International
