Risultati del lavoro del team di test del software

I risultati del lavoro di test sono documenti condivisi con le parti interessate durante lo sviluppo del software. In questa sezione trovi i seguenti elementi.

Apri il diagramma a grandezza naturale ↗

Risultati del lavoro del team di test del software

• Strategia di test del software
• Piano di test del software
• Scenari e casi di test del software
• Metriche di test del software
• Metriche di prodotto
• Metriche di processo
• Documentazione di test del software
• Rapporti di test del software
• Rapporti giornalieri sullo stato dei test
• Rapporti sugli incidenti
• Rapporto finale di chiusura dei test

Strategia di test del software

Una strategia di test indica come condurre le attività di test del progetto. Suddividi il lavoro in processi più piccoli e ben definiti. La strategia aiuta il team a stimare tempo, impegno e risorse e facilita la pianificazione, la gestione e il monitoraggio dei progressi.

Piano di test del software

Un piano di test definisce la strategia generale, l’ambiente e i livelli di test. Spiega come analizzare i risultati e quali metriche usare. Registra anche i criteri di uscita di ogni fase e le stime dell’impegno e dei costi dei test.

Apri il diagramma a grandezza naturale ↗

Piano di test del software

Scenari e casi di test del software

Uno scenario di test descrive una situazione ipotetica per valutare il software in modo strutturato. Può essere complesso come una storia. Un caso di test dice direttamente che cosa fare, quali dati fornire e quale risultato attendersi. Di norma, un caso di test occupa una riga, mentre uno scenario offre a chi testa un contesto più ampio da esplorare.

Apri il diagramma a grandezza naturale ↗

Scenari e casi di test del software

Nel 2003 Cem Kaner descrisse il test basato su scenari come un modo per esplorare situazioni realistiche. I casi di test dettagliati continuano a documentare passaggi, dati di ingresso e risultati attesi. Mantenere questo livello di dettaglio può richiedere più impegno.

I casi di test dicono direttamente a chi testa che cosa fare e come verificare il software.

Apri il diagramma a grandezza naturale ↗

Scenari e casi di test del software

Metriche di test del software

Una metrica del software è un’unità di misura che serve a valutare una caratteristica del software. Le metriche di test valutano la qualità e indicano quanto il sistema è pronto durante lo sviluppo. Perché misurare? Possiamo migliorare ciò che misuriamo perché possiamo controllarlo. In ogni fase dello sviluppo, le decisioni si basano sulle metriche della fase precedente. Le metriche di test si dividono in due gruppi.

1. Le misure dirette, o metriche di base, sono dati grezzi raccolti da chi analizza i test per descrivere lo stato del progetto, ad esempio il numero di casi di test creati o eseguiti.
2. Le misure indirette, o metriche calcolate, trasformano i dati di base in informazioni più utili sul progetto, ad esempio la percentuale di completamento o di copertura dei test.

Metriche di prodotto

Le metriche di prodotto guidano il miglioramento della qualità. Una valutazione regolare aiuta il team a individuare per tempo le caratteristiche da correggere. Le metriche misurano gli aspetti seguenti.

• Dimensione
• Complessità
• Aspetti di progettazione
• Prestazioni
• Qualità

Metriche di processo

Le metriche di processo individuano come migliorare il modo di lavorare, risparmiando tempo e fatica. Per valutare i progressi, confronta i risultati con l’obiettivo del processo. Monitorare le attività di test può rendere un progetto più efficiente ed efficace. Nello sviluppo del software, queste metriche riguardano i seguenti ambiti.

• Sviluppo del software
• Manutenzione del software
• Test del software

Documentazione di test del software

La documentazione di test registra le attività prima o durante i test. Tra i documenti principali figurano i seguenti.

• Piano di test
• Scenario di test
• Caso di test
• Matrice di tracciabilità

Rapporti di test del software

I rapporti seguenti supportano il lavoro di test.

• Rapporti giornalieri sullo stato dei test
• Rapporti sugli incidenti
• Rapporto finale di chiusura dei test

Rapporti giornalieri sullo stato dei test

I rapporti giornalieri tengono informati il team di test e le parti interessate del progetto e del programma. Chi gestisce il progetto può consultare il conteggio dei difetti della giornata, i casi eseguiti e il lavoro svolto da ogni tester. Rispondi alle domande seguenti.

1. Quanti casi di test erano previsti per la giornata?
2. Quanti sono stati eseguiti?
3. Quanti difetti ha segnalato il team?
4. Quanti difetti erano critici?
5. Dove si trovano i rapporti dettagliati, compreso il foglio dei difetti e delle esecuzioni dei test?

Rapporti sugli incidenti

I rapporti sugli incidenti coordinano test e sviluppo. La gestione degli incidenti registra quanto segue.

• Un confronto tra i risultati effettivi e quelli attesi
• Il motivo della differenza in un test fallito, per esempio un’automazione difettosa, un caso di test inadeguato o un guasto effettivo del software

In caso di guasto effettivo, prepara un rapporto sull’incidente con le informazioni seguenti.

• Identificazione
• Qual è l’identificativo di ogni rapporto?
• Qual è l’oggetto del test?
• Versione dell’applicazione sottoposta a test
• Dettagli sull’ambiente di test, inclusi hardware e software
• Nome di chi deve valutare e risolvere l’incidente per il team di sviluppo
• Quando è stato osservato il guasto?
• Classificazione
• Stato
• Gravità
• Priorità
• Requisito
• Causa
• Descrizione del problema
• Descrizione del guasto
• Dettagli del caso di test
• Commenti di chi ha eseguito il test
• Commento di chi ha apportato la modifica
• Eventuali riferimenti

Rapporto finale di chiusura dei test

Il responsabile dei test prepara un rapporto di chiusura quando si soddisfano i criteri di uscita o quando terminano i test. Le parti interessate e i clienti esaminano poi il rapporto. Includi i casi di test eseguiti con successo e gli eventuali difetti ancora aperti che verranno corretti dopo il rilascio.