Ciclo di vita dei test del software: fasi, strumenti e migliori pratiche

Le sei fasi sono:

1. Analisi dei requisiti
2. Pianificazione dei test
3. Sviluppo dei casi di test
4. Configurazione dell'ambiente di test
5. Esecuzione dei test
6. Chiusura dei test

Puoi utilizzare queste sei fasi sia per testare una nuova funzionalità, sia per un rilascio completo o una correzione urgente. Lo stesso approccio strutturato si applica ogni volta.

Perché lo STLC è importante: 5 vantaggi principali

Lo STLC è importante perché aiuta a individuare prima i difetti, e questo influisce direttamente sui costi. La regola generale è che correggere i difetti in produzione è esponenzialmente più costoso che correggerli durante i test.

Ecco cosa offre al tuo team uno STLC chiaro:

• Rilevamento precoce dei difetti: esaminare i requisiti prima di scrivere un caso di test fa emergere le ambiguità prima che si trasformino in difetti costosi.
• Copertura dei test prevedibile: un processo definito garantisce che nulla venga trascurato tra uno sprint e l'altro o durante i passaggi di consegne.
• Documentazione standardizzata: ogni fase produce artefatti (ad esempio piani di test, casi di test e registri dei difetti) che creano una traccia di verifica e supportano la conformità.
• Responsabilità chiare: quando ogni fase ha ruoli e criteri di uscita definiti, misurare i progressi e individuare i colli di bottiglia diventa più semplice.
• Riduzione dei costi complessivi: i test strutturati riducono il lavoro da rifare, le correzioni urgenti non pianificate e le conseguenze operative dei difetti in produzione.

Ho riscontrato che i team che saltano le fasi formali dello STLC non risparmiano tempo. Spendono quel tempo in seguito nella risposta agli incidenti e nelle correzioni di emergenza.

Ciclo di vita dei test del software a confronto con il ciclo di vita dello sviluppo del software

L'SDLC copre l'intero processo di distribuzione del software, dai requisiti alla progettazione, allo sviluppo, ai test, alla distribuzione e alla manutenzione. Lo STLC è parte dell'SDLC e comprende esclusivamente le attività di test.

Utilizza questa tabella per confrontare i due cicli:

Dimensione	SDLC	STLC
Ambito	Distribuzione completa del software	Solo attività di test
Focus	Creazione e distribuzione del software	Verifica della qualità e rilevamento dei difetti
Team principale	Sviluppatori, responsabili di prodotto, architetti	Ingegneri QA, responsabili dei test, responsabili della gestione dei test
Risultati finali	Software funzionante, documentazione dell'architettura, versione di rilascio	Piani di test, casi di test, rapporti sui difetti, rapporti riepilogativi dei test
Obiettivo	Distribuire il prodotto	Convalidare che il prodotto soddisfi i requisiti

Ruoli e responsabilità nello STLC

Ogni fase dello STLC si basa su persone specifiche che svolgono attività specifiche. Ecco chi è responsabile di cosa:

• Responsabile dei test: Definisce la strategia complessiva di testing, gestisce budget e tempistiche e riferisce lo stato della qualità agli stakeholder. È responsabile del piano di test.
• Responsabile dei test: Coordina le attività quotidiane di testing, assegna il lavoro al team e monitora i progressi rispetto ai criteri di uscita.
• Ingegnere QA: Scrive ed esegue i casi di test, registra i difetti ed esegue i test di regressione. È la spina dorsale della fase di esecuzione.
• Ingegnere dell'automazione: Progetta e mantiene gli script di test automatizzati. È responsabile del framework di automazione e dell'integrazione CI/CD.
• Analista aziendale: Supporta l'analisi dei requisiti chiarendo i criteri di accettazione e risolvendo le ambiguità nelle storie utente.
• Sviluppatore: Corregge i difetti segnalati e partecipa ai test unitari. Nel testing anticipato, gli sviluppatori vengono coinvolti prima nella progettazione dei test.

Nei team più piccoli, una persona spesso ricopre più ruoli. Un ingegnere QA potrebbe occuparsi anche dell'automazione e il responsabile dei test potrebbe svolgere anche il ruolo di responsabile del testing. Va bene; assicurati solo che ogni responsabilità sia assegnata esplicitamente, anziché essere data per scontata.

UNISCITI ALLA COMUNITÀ

Arricchisci la tua casella di posta con più saggezza sulla leadership tecnologica per offrire software e sistemi migliori.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Name*

First name Last name

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Business email*

Create Password*

This field is hidden when viewing the form

LinkedIn profile

This field is hidden when viewing the form

Company's AI adoption maturity

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

Le 6 fasi del ciclo di vita del testing del software

1. Analisi dei requisiti

L'analisi dei requisiti è il punto di partenza del testing, prima ancora che venga scritto un singolo caso di test. Il team esamina i requisiti funzionali e non funzionali per comprendere cosa dovrebbe fare il sistema e individuare tutto ciò che non è chiaro o non è verificabile.

Attività principali di questa fase:

• Esaminare i requisiti: Analizzare i documenti dei requisiti aziendali, le storie utente e i criteri di accettazione.
• Identificare i requisiti verificabili: Segnalare tutto ciò che non presenta un risultato misurabile e verificabile.
• Definire l'ambito dei test: Decidere cosa sarà e cosa non sarà testato in questo ciclo.
• Individuare tempestivamente i rischi: Portare alla luce i requisiti ambigui, contraddittori o tecnicamente rischiosi.
• Documentare le questioni aperte: Inviare le ambiguità irrisolte all'analista aziendale o al responsabile del prodotto affinché vengano risolte.

Il principale risultato di questa fase è una matrice di tracciabilità dei requisiti (RTM). Essa collega ogni requisito ai casi di test che lo verificheranno.

Criteri di ingresso: Sono disponibili i documenti dei requisiti approvati.
Criteri di uscita: Tutti i requisiti verificabili sono stati identificati; la RTM è stata redatta; le ambiguità sono state registrate e inviate per la risoluzione.

2. Pianificazione dei test

La pianificazione dei test definisce come verrà svolto il testing. Il responsabile dei test produce il piano di test. Questo documento stabilisce l'ambito, l'approccio, le risorse, la pianificazione e il registro dei rischi per le attività di testing.

Un piano di test solido comprende:

• Obiettivi dei test: Cosa si sta verificando e perché.
• Tipi di testing: Funzionale, di regressione, delle prestazioni, di sicurezza, ecc. (a seconda di quelli applicabili alla release).
• Piano delle risorse: Chi fa cosa e quando.
• Pianificazione: Milestone, finestre di testing e date di passaggio di consegne.
• Rischi e mitigazione: Cosa potrebbe bloccare il testing e il piano di emergenza per ogni rischio.
• Criteri di ingresso e di uscita: Le condizioni che regolano ogni fase.
• Strumenti: Gli strumenti di gestione dei test, automazione e tracciamento dei difetti che il team utilizzerà.

Considera il piano di test come un documento dinamico. Nei team agili, viene aggiornato a ogni sprint anziché essere scritto una volta e poi dimenticato.

Criteri di ingresso: Requisiti analizzati; RTM disponibile.
Criteri di uscita: Piano di test esaminato e approvato dagli stakeholder.

3. Sviluppo dei casi di test

Lo sviluppo dei casi di test è la fase in cui gli ingegneri QA scrivono, esaminano e definiscono la versione di riferimento dei test effettivi. Ogni caso di test è collegato a un requisito specifico nella RTM. Nel loro insieme, dovrebbero coprire l'intero ambito concordato nel piano di test.

Ogni caso di test dovrebbe includere:

• ID e nome del caso di test
• Prerequisiti: Lo stato in cui deve trovarsi il sistema prima dell'esecuzione.
• Passaggi del test: Azioni numerate, chiare e ripetibili.
• Risultato previsto: L'output o il comportamento esatto da convalidare.
• Risultato effettivo: Compilato durante l'esecuzione.
• Stato superato/non superato

Questa fase produce anche i dati di test, ovvero gli input effettivi che il team utilizza durante l'esecuzione. È importante preparare correttamente i dati di test, poiché dati errati producono risultati fuorvianti.

Criteri di ingresso: Piano di test approvato; RTM finalizzata.
Criteri di uscita: Casi di test revisionati e approvati formalmente; dati di test preparati e convalidati.

4. Configurazione dell'ambiente di test

L'ambiente di test è l'infrastruttura su cui il team esegue i test. Include server, database, sistemi operativi, browser, configurazioni di rete e qualsiasi integrazione da cui dipende l'applicazione.

Questa fase ha due obiettivi: preparare l'ambiente e verificarne la stabilità prima dell'inizio dell'esecuzione.

Le attività comuni includono:

• Provisioning dell'infrastruttura: Configurazione di server, container o ambienti cloud che rispecchiano la produzione.
• Installazione della versione in esame: Distribuzione della versione sottoposta a test nell'ambiente.
• Esecuzione di test preliminari sull'ambiente: Esecuzione di un controllo rapido per confermare che la configurazione funzioni prima dell'esecuzione completa dei test.
• Configurazione dei dati: Inserimento dei dati di test nell'ambiente.

I problemi dell'ambiente sono una delle cause più comuni dei ritardi nei test. Considererei il test preliminare dell'ambiente un controllo vincolante prima dell'inizio dell'esecuzione. Se l'ambiente non è stabile, i risultati dei test non saranno significativi.

Criteri di ingresso: Casi di test finalizzati; specifiche dell'ambiente definite.
Criteri di uscita: Ambiente stabile; test preliminare superato.

5. Esecuzione dei test

L'esecuzione dei test è la fase in cui il team esegue i casi di test e registra i risultati. Per ogni caso di test che non viene superato, l'ingegnere QA registra un difetto e lo assegna al team di sviluppo per la correzione.

Il ciclo di esecuzione funziona in genere nel modo seguente:

1. Eseguire i casi di test sulla versione in esame.
2. Registrare i risultati superato/non superato nel proprio strumento di gestione dei test.
3. Segnalare i difetti indicando i passaggi per riprodurli, la gravità e le prove a supporto.
4. Il team di sviluppo analizza e corregge il difetto.
5. Il team QA ripete i test sui difetti corretti.
6. Eseguire test di regressione per confermare che le correzioni non abbiano compromesso le funzionalità esistenti.
7. Ripetere il processo fino al raggiungimento dei criteri di uscita.

Tenere traccia dello stato dei difetti è importante tanto quanto monitorare l'avanzamento dell'esecuzione. Un arretrato di difetti ad alta gravità non risolti indica che la versione non è pronta, anche se la percentuale di esecuzione appare elevata.

Criteri di ingresso: Ambiente stabile; casi di test approvati; versione distribuita.
Criteri di uscita: Tutti i casi di test pianificati eseguiti; difetti con gravità superiore a quella concordata risolti e sottoposti nuovamente a test; metriche dei criteri di uscita soddisfatte.

6. Chiusura dei test

La chiusura dei test conclude il ciclo di test e produce gli artefatti necessari al team per il passaggio di consegne, la conformità e il miglioramento. Spesso viene affrettata o saltata a causa della pressione delle scadenze, e questo è un errore.

Attività principali:

• Valutare i criteri di uscita: Confermare che tutte le condizioni di uscita previste dal piano di test siano soddisfatte.
• Redigere il rapporto riepilogativo dei test: Documentare i risultati, le metriche dei difetti, la copertura raggiunta e i rischi residui.
• Archiviare gli artefatti di test: Conservare i casi di test, i dati di test e i registri dei difetti in un archivio condiviso per riferimento futuro.
• Condurre una retrospettiva: Individuare cosa ha funzionato, cosa non ha funzionato e cosa migliorare nel ciclo successivo.

Il rapporto riepilogativo dei test è il prodotto finale più importante di questa fase. Gli stakeholder lo utilizzano per decidere se procedere o meno con il rilascio. Redigerlo in modo chiaro e assicurarsi che affronti i rischi aperti, non solo le percentuali di superamento.

Criteri di ingresso: Esecuzione dei test completata; difetti risolti o rinviati con motivazione documentata.
Criteri di uscita: Rapporto riepilogativo dei test approvato; artefatti di test archiviati.

Strumenti essenziali per ogni fase dello STLC

Ecco le mie scelte per i migliori strumenti per il ciclo di vita del testing del software:

I clic sui link sottostanti possono generare una commissione, che sostiene i nostri test e le nostre recensioni indipendenti di software e servizi. Scopri di più su come manteniamo la trasparenza.

1. 1. QA.tech — Ideale per test end-to-end guidati dall'IA
2. 2. Kualitee — Ideale per gestione casi di test + tracciamento bug
3. 3. Testpad — Ideale per la gestione dei test in stile checklist
4. 4. BugHerd — Ideale per il tracciamento visivo dei bug
5. 5. BugBug — Ideale per il testing dei browser
6. 6. Testiny — Ideale per utenti Jira
7. 7. TestGrid — Ideale per l'esecuzione parallela dei test
8. 8. Appsurify TestBrain — Ideale per il testing basato sul rischio
9. 9. QA Wolf — Ideale per la collaborazione del team
10. 10. Tricentis Testim — Ideale per automazione scalabile

Sfide comuni dello STLC e come superarle

Ecco i problemi più comuni e come affrontarli:

• Requisiti ambigui: Criteri di accettazione poco chiari portano a test che convalidano l'aspetto sbagliato. Risolvete il problema durante l'analisi dei requisiti. Non aspettate l'esecuzione per scoprire che un requisito non è verificabile.
• Instabilità dell'ambiente: Un ambiente di test instabile fa sprecare cicli di lavoro e riduce la fiducia nei risultati. Investite nell'ambiente come codice utilizzando Docker o Kubernetes, in modo da poter avviare ambienti coerenti e riproducibili su richiesta.
• Test automatizzati instabili: Alcuni fallimenti dei test automatizzati sono dovuti a test instabili, non a difetti reali. Verificate regolarmente la vostra suite di automazione e riscrivete i test che falliscono in modo incostante.
• Tempistiche ristrette: Quando aumenta la pressione sulle scadenze, i team riducono i test (di solito quelli di regressione). Applicate test basati sul rischio per dare priorità alle aree ad alto impatto invece di ridurre i test indiscriminatamente.
• Team isolati: Quando gli sviluppatori e il team QA lavorano separatamente, la classificazione dei difetti rallenta. Create canali condivisi, cadenze di classificazione e definizioni concordate della gravità prima dell'inizio dell'esecuzione.
• Pressione sul ROI dell'automazione: L'automazione richiede un investimento iniziale e una manutenzione continua. Iniziate con casi di test stabili e ad alta frequenza (ad esempio, flussi di accesso, contratti API e percorsi di pagamento) prima di estendervi ai casi limite.

STLC in Agile e DevOps: spostamento a sinistra e test continui

Le sei fasi dello STLC si applicano ancora ad Agile e DevOps, ma si comprimono e si ripetono. Invece di un unico ciclo lungo per ogni rilascio, il team esegue una versione più breve a ogni sprint.

• Spostamento a sinistra dei test: Significa spostare i test a una fase precedente dello sviluppo. I tester esaminano le storie utente durante la pianificazione dello sprint, i casi di test esistono prima che venga scritto il codice e gli sviluppatori scrivono i test unitari insieme alle funzionalità. Prima si trova un difetto, meno costa correggerlo.
• Test continui: Integrano i test automatizzati nella pipeline CI/CD. Ogni commit avvia un'esecuzione dei test e la pipeline si interrompe rapidamente quando compare una regressione. Gli sviluppatori ricevono un feedback immediato senza dover attendere una finestra di test dedicata.

Per adattare lo STLC ad Agile e DevOps, seguite queste pratiche:

• Integrare il QA nelle cerimonie dello sprint: I tester dovrebbero partecipare alla pianificazione dello sprint per esaminare i criteri di accettazione e segnalare i problemi di verificabilità prima dell'inizio dello sviluppo.
• Automatizzare la regressione insieme alle funzionalità: Non create una suite di regressione dopo il rilascio. Costruitela man mano che ogni funzionalità viene rilasciata.
• Utilizzare i flag delle funzionalità: Distribuite il codice dietro un flag, quindi testatelo in produzione prima di abilitarlo per gli utenti.
• Trattare gli ambienti come codice: Utilizzate l'infrastruttura come codice per predisporre automaticamente ambienti coerenti a ogni build.

Secondo la mia esperienza, il cambiamento più importante è culturale. Far lavorare sviluppatori e tester come un unico team, invece che in fasi sequenziali, è ciò che rende efficace il testing Agile.

Il ruolo dell'automazione e dell'AI nello STLC moderno

L'automazione fa parte dello STLC, ma non sostituisce la strategia di test. È un acceleratore per i tipi di test appropriati.

Dove automatizzare

Automatizzate i test che hanno alta frequenza, sono stabili e richiedono molto tempo per essere eseguiti manualmente:

• Test di regressione: Il caso d'uso con il ROI più elevato per l'automazione. Eseguite l'intera suite di regressione a ogni build.
• Test delle API: Sono rapidi, affidabili e più facili da manutenere rispetto ai test dell'interfaccia utente.
• Test di fumo: Automatizzate la suite di test di fumo affinché la convalida dell'ambiente richieda minuti, non ore.
• Test di carico e delle prestazioni: Strumenti come k6 e Apache JMeter possono simulare migliaia di utenti simultanei. È impossibile replicare manualmente questa situazione.

Come l'AI sta cambiando lo STLC

L'AI sta apportando cambiamenti significativi al modo in cui vengono eseguiti i test durante l'intero ciclo di vita:

• Generazione dei casi di test: gli strumenti di IA analizzano i requisiti o le storie utente e suggeriscono casi di test che il tuo team potrebbe altrimenti non prendere in considerazione.
• Test autoriparanti: i framework basati sull'IA rilevano quando un elemento dell'interfaccia utente cambia e aggiornano automaticamente il selettore del test, riducendo il carico di manutenzione.
• Analisi predittiva dei difetti: alcune piattaforme analizzano i dati storici sui difetti per prevedere quali aree di una base di codice presentano il rischio più elevato in una determinata release.
• Test visivi: gli strumenti basati sull'IA confrontano gli screenshot pixel per pixel e segnalano le modifiche al layout senza selettori XPath fragili.

Considero l'IA nei test nello stesso modo in cui considero l'automazione in generale: gestisce le attività ripetitive basate sulla ricerca di schemi, così i tuoi ingegneri QA possono concentrarsi sui test che richiedono giudizio umano.

Buone pratiche per il ciclo di vita dei test del software

Segui queste pratiche per ottenere il massimo dal tuo STLC in ogni fase:

• Inizia i test durante la definizione dei requisiti: quanto prima il team QA viene coinvolto, tanto meno ambiguità arrivano allo sviluppo.
• Mantieni aggiornato l'RTM: mantieni aggiornata la matrice di tracciabilità dei requisiti, così le lacune nella copertura sono visibili in tempo reale.
• Applica test basati sul rischio: concentra prima gli sforzi sulle aree ad alto rischio e ad alto impatto, soprattutto quando il tempo è limitato.
• Rivedi i casi di test prima dell'esecuzione: i casi di test sottoposti a revisione tra pari individuano lacune e supposizioni errate prima che producano risultati fuorvianti.
• Integra i test nella CI/CD: i test automatizzati dovrebbero essere eseguiti a ogni commit, non solo prima del rilascio.
• Esegui retrospettive a ogni ciclo: usa ciò che impari da ogni STLC per migliorare quello successivo.

Metriche chiave da monitorare

Questi KPI forniscono il segnale più chiaro sulla qualità dei test e sullo stato di salute del processo:

Metrica	Cosa misura	Perché è importante
Densità dei difetti	Difetti per unità di codice o funzionalità	Indica la qualità del codice e l'accuratezza dei test
Tasso di superamento dei casi di test	% di casi di test superati in un ciclo	Monitora lo stato di salute complessivo della build
Fuoriuscita dei difetti	Difetti rilevati in produzione rispetto a quelli rilevati nei test	Misura quanti difetti non sono stati individuati dai test
Copertura dei test	% di requisiti coperti dai casi di test	Garantisce che nulla rimanga non testato
Tempo di risoluzione dei difetti	Tempo medio dalla registrazione alla correzione	Riflette la reattività del team di sviluppo
Tasso di esecuzione dei test	% di casi di test pianificati eseguiti	Monitora se i test sono in linea con la pianificazione

Mantieni aggiornate le tue conoscenze sui test

Se vuoi rimanere aggiornato sulle tendenze dell'ingegneria della qualità e sugli strumenti che stanno plasmando lo sviluppo moderno, la newsletter di The CTO Club offre ogni settimana direttamente nella tua casella di posta elettronica approfondimenti di CTO, direttori dell'ingegneria e leader tecnici.