Operazione: Determinazione dei risultati del test
Questa attività descrive in che modo registrare esattamente i risultati di test e quali tipi di azioni supplementari sono richiesti.
Scopo

Lo scopo di questo compito è di:

  • Effettuare valutazioni di riepilogo continuative della qualità percepita del prodotto
  • Identificare e catturare i risultati dettagliati del test
  • Proporre delle azioni di correzione appropriate per risolvere i difetti di qualità
Relazioni
Passi
Controllo di tutti gli incidenti ed errori del test
Scopo:  Per esaminare ciascun incidente e acquisire maggiori conoscenze sui problemi risultanti. 

In questa attività, i file log dei test vengono analizzati per ottenere risultati significativi, riguardanti le differenze tra i risultati previsti ed i risultati effettivi di ciascun test. Identificare e analizzare ciascun incidente ed errore. E' consigliabile apprendere quanto più possibile di ciascuna ricorrenza.

Controllare gli incidenti duplicati, i sintomi comuni e altre relazioni tra gli incidenti. Queste condizioni spesso forniscono un prezioso controllo della causa principale di un gruppo di incidenti.

Creazione e manutenzione delle richieste di modifica
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:

Verifica dei dati degli incidenti Inizio pagina

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.

Chiarificazione dei dettagli della richiesta di modifica Inizio pagina

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.

Indicazioni sulla gravità dell'impatto e sulla priorità di risoluzione Inizio pagina

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.

Registrazione separata di richieste di modifica aggiuntive

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.

Analisi e valutazione dello stato
Scopo:  Per calcolare e consegnare le misurazioni e gli indicatori chiave del test. 

Argomenti secondari:

Distribuzione degli incidenti

Analizzare gli incidenti in base all'ubicazione di distribuzione, come l'area funzionale, al rischio qualità, al tester e allo sviluppatore assegnati.

Eseguire una ricerca dei modelli nella distribuzione, come le aree funzionali che potrebbero avere un conteggio dei difetti superiore alla media. Inoltre, individuare gli sviluppatori ed i tester che potrebbero essere sovraccarichi e che ha visto peggiorare la relativa qualità di lavoro.

Completamento dell'esecuzione del test

Per valutare la copertura di esecuzione del test, è necessario revisionare i log di test per determinare:

  • Il rapporto tra quanti test (script di test o scenari di test) sono stati eseguiti in questo ciclo e un numero totale di test eseguiti per tutti gli elementi test di destinazione pianificati.
  • Il rapporto degli scenari di testi eseguiti correttamente.

L'obiettivo è di garantire che un numero sufficiente di test destinato a questo ciclo sia stato eseguito in modo utile. Se ciò non è possibile per accrescere quei dati di esecuzione, possono essere identificati uno o più criteri di complemento test aggiuntivi, basati sulle seguenti condizioni:

  • Rischio qualità o priorità
  • Copertura basata sulle specifiche (requisiti, ecc.)
  • Necessità di business o priorità
  • Copertura basata sul codice

Consultare Concetto: Misurazioni chiave del test, completamento test basato sui requisiti.

Registrare e presentare i risultati del test in un prospetto di valutazione per questo ciclo di test.

Statistiche delle richieste di modifica

Per analizzare i difetti, è necessario revisionare e analizzare le misurazioni scelte come parte della propria strategia di analisi dei difetti. Le misurazioni dei difetti più comunemente utilizzate includono diverse misurazioni (visualizzate spesso in un grafico):

  • Densità difetto - il numero dei difetti è mostrato come funzione di uno o due attributi di difetti (come la distribuzione su un'area funzionale o il rischio qualità confrontato allo stato o alla gravità).
  • Trend difetto - il conteggio dei difetti è mostrato come una funzione nel tempo.
  • Durata stato del difetto - un particolare report di densità del difetto in cui il numero dei difetti viene mostrato come funzione del periodo di tempo in cui un difetto resta in un determinato stato (aperto, nuovo, attesa di verifica. ecc.)

Per comprendere maggiormente i trend emergenti nel tempo, mettere a confronto le misurazioni di questo ciclo di test con il totale parziale dell'iterazione corrente e con quelli dell'analisi delle precedenti iterazioni.

Si consiglia di proporre i risultati nel formato di diagramma con le rilevazioni di supporto su richiesta.

Valutazione dell'esperienza di qualità corrente
Scopo:  Per fornire un feedback sulla qualità percepita o sperimentata nel prodotto software. 

Creare un riepilogo dell'esperienza di qualità corrente, evidenziando gli aspetti positivi e negativi della qualità dei prodotti software.

Valutazione dei rischi di qualità in sospeso
Scopo:  Per fornire un feedback sulle restanti aree di rischio che possono maggiormente esporre a rischi il progetto. 

Identificare e descrivere quelle aree che non sono state ancora definite in termini di rischi della qualità e indicare il relativo impatto ed esposizione rispetto al team.

Fornire un'indicazione sul livello di priorità che si considera abbia ciascun rischio di qualità in sospeso e utilizzare la priorità per indicare l'ordine in cui queste problematiche devono essere affrontate.

Valutazione del completamento test
Scopo:  Per effettuare una valutazione di riepilogo dell'analisi di completamento del test. 

Sulla base del lavoro descritto nella fase completamento dell'esecuzione di test, fornire una breve dichiarazione di riepilogo sullo stato e sulle informazioni che i dati rappresentano.

Stesura del riepilogo della valutazione del test
Scopo:  Per comunicare i risultati di test ai portatori d'interesse ed effettuare una valutazione obiettiva sulla qualità e sullo stato del test. 

Presentare i risultati di test per questo ciclo in un riepilogo della valutazione del test. Questa fase è richiesta per sviluppare la stesura iniziale del riepilogo. Ciò viene effettuato assemblando le precedenti informazioni raccolte in un prospetto di riepilogo consultabile. A seconda dei portatori d'interesse e del contesto del progetto, l'effettivo formato e contenuto del riepilogo cambierà.

Spesso è una buona idea distribuire la bozza iniziale ad un gruppo ristretto di portatori d'interesse in modo da ottenere un feedback da integrare prima di eseguire la divulgazione ad un pubblico più ampio.

Segnalazione ai portatori d'interesse di risultati chiave
Scopo:  Per promuovere e pubblicizzare il riepilogo della valutazione. 

Qualsiasi mezzo è appropriato per pubblicizzare queste informazioni. Si consiglia di divulgare queste informazioni su un sito del progetto centralizzato o presentarle in regolari riunioni sullo stato per consentire la raccolta dei feedback e per stabilire le prossime azioni.

Occorre essere consapevoli che rendono pubblicamente disponibili i riepiloghi sulle valutazioni può a volte essere un sensibile problema di opportunità. Trattare con il responsabile sviluppo per presentare dei risultati in un modo che rispecchino un equo ed accurato riepilogo delle proporre scoperte, tuttavia rispettare il lavoro degli sviluppatori.

Valutazione e verifica dei risultati
Scopo:  Verificare che il compito sia stato completato in modo appropriato e che i prodotti di lavoro risultanti siano accettabili.  

Una volta completato il lavoro è bene verificare che questo sia stato di buona qualità, e che non si siano consumate unicamente grosse quantità di carta. È necessario valutare se il proprio lavoro sia stato all'altezza, e che sia completo abbastanza da essere utile ai membri del team che l'utilizzeranno in seguito. Dove possibile, utilizzare l'elenco di controllo fornito da RUP per verificarne la qualità e la completezza.

Richiedere ai componenti del team di concentrarsi sul flusso di operazioni che hanno come input il vostro lavoro e partecipare all'analisi effettuata durante il suo corso. Procedere in questo modo mentre si ha ancora tempo a disposizione per prendere decisioni e discutere delle loro considerazioni. È inoltre necessario considerare il proprio lavoro nei confronti dei prodotti di lavoro di input chiave, per assicurarsi che siano stati rappresentati in modo accurato e sufficiente. Potrebbe essere utile chiedere all'autore del prodotto di lavoro di input di revisionare il vostro lavoro su queste basi.

Tenere presente che RUP è un processo di produzione iterativo e che in molti casi i prodotti di lavoro evolvono nel tempo. Su questa base è spesso non necessario o addirittura controproducente, definire in modo completo un prodotto di lavoro che verrà utilizzato solo parzialmente o affatto, nel lavoro immediatamente successivo. Ciò si determina a causa dell'elevata probabilità che le condizioni presenti intorno al prodotto di lavoro cambieranno - e le supposizioni fatte quando il prodotto di lavoro è stato creato valutate non corrette - prima che il prodotto venga utilizzato, determinando come risultato uno spreco di impegno lavorativo e una rilavorazione dispendiosa. Non effettuare inoltre troppi cicli sulla presentazione per evitare il detrimento del valore del contenuto. Negli ambienti di progetto dove la presentazione ha la medesima importanza e valore economico di un componente distribuibile, è bene considerare la possibilità di utilizzare una risorsa amministrativa per il compito di presentazione.



Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni