Scopo:
|
Per immettere le informazioni sulle richieste di modifica in un tool di controllo per la valutazione,
gestione e risoluzione.
|
Le differenze indicano potenziali difetti negli elementi test di destinazione e devono essere immesse in un sistema di
controllo come incidenti o richieste di modifica, con riferimento alle appropriate azioni di correzione che vanno
intraprese.
Argomenti secondari:
Accertarsi che vi siano dati precisi supportati e disponibili. Raccogliere i dati da allegare direttamente alla
richiesta di modifica o indicare dove i dati possono essere ottenuti separatamente.
Quando possibile, verificare che il problema sia riproducibile. I problemi riproducibili hanno più probabilità di
ricevere l'attenzione degli sviluppatori ed essere conseguentemente corretti; un problema che non può essere riprodotto
rende difficile il lavoro del personale di sviluppo e impegna preziose risorse di programmazione in ricerche senza
risultati. Si consiglia di continuare la registrazione di questi incidenti, ma di separare gli incidenti non
riproducibili da quelli riproducibili.
E' importante comprendere le richieste di modifica, specialmente il titolo. Accertarsi che il titolo sia netto e
conciso, articolando chiaramente il problema specifico. Un titolo breve è utile per gli elenchi di difetti di riepilogo
e per le discussioni nelle riunioni sullo stato CCB.
E' importante che la descrizione dettagliata della richiesta di modifica sia facilmente comprensibile e priva di
ambiguità. Una buona idea è registrare le richieste di modifica quanto prima possibile, ma prendere il tempo necessario
per migliorare ed estendere le proprie descrizioni prima che vengano visualizzate dal personale di sviluppo.
Fornire delle soluzioni candidate, quanto più pratiche possibili. Ciò aiuta a ridurre le restanti ambiguità nella
descrizione, consentendo spesso di chiarificare. Inoltre, aumenta le probabilità che la soluzione sia legata alle
proprie obiezioni. Inoltre, ciò mostra che il team di test non è solo preparato per individuare i problemi, ma anche di
identificare le soluzioni appropriate.
Altri dettagli da includere sono le catture di immagini dello schermo, i file dati del testo, gli script di test
automatizzato, gli output dai programmi di utilità dei diagnostici e tutte le altre informazioni che potrebbero essere
utili agli sviluppatori per isolare e correggere gli errori sottostanti.
Fornire un'indicazione al personale di gestione e di sviluppo sulla severità del problema. In team più grandi
l'effettiva priorità di risoluzione viene di solito determinata dal team di gestione; tuttavia, si può lasciare ai
singoli indicare la loro priorità di risoluzione preferita e successivamente adattare come necessario. Come regola
genera le si consiglia di assegnare, per impostazione predefinita, una priorità di risoluzione media alle Richieste di
modifica e elevare o abbassare quella priorità caso per caso come necessario.
Potrebbe essere necessario effettuare una distinzione tra l'impatto che la richiesta di modifica avrà sull'ambiente di
produzione se non è specificato e l'impatto che la richiesta di modifica avrà sull'impegno lavorativo di test se non è
specificato; è tanto importante per il team di gestione sapere quando un difetto sta influendo sull'impegno lavorativo
di test quanto di essere consapevoli della severità per gli utenti.
Talvolta è difficile individuare in anticipo il motivo per cui sono necessari entrambi gli attributi. E' possibile che
un incidente sia veramente grave, come un'interruzione del sistema, ma le azioni richieste per riprodurlo possono
inverosimilmente verificarsi. In questo caso il team può indicare come alta la gravità, ma indicare una priorità di
risoluzione molto bassa.
Gli incidenti spesso richiamano il vecchio detto "Dove c'è il fumo, c'è il fuoco"; mentre si identifica e si registra
una richiesta di modifica, molto frequentemente si identificano altre problematiche che devono essere segnalate. Non
aggiungere semplicemente questi risultati aggiuntivi alla richiesta di modifica esistente: se le informazioni sono
direttamente correlate e consentono di risolvere in modo migliore il problema esistente, ciò è corretto. Se le altre
problematiche sono diverse, la loro identificazione rispetto ad una richiesta di modifica esistente potrebbe non
consentirne l'elaborazione, non determinare un'assegnazione di priorità appropriata oppure potrebbe influenzare la
velocità con la quale vengono affrontate problematiche di altro tipo.
|