La gestione della qualità del software è una disciplina che ha subito profondi cambiamenti con l'evoluzione dei cicli di vita dei progetti IT. Sebbene l'obiettivo rimanga costante – garantire la conformità di uno strumento alle esigenze aziendali – i metodi per raggiungerlo si sono spostati da un rigoroso modello di controllo manuale a un modello di integrazione continua in cui i dati sono dinamici.
L'era della documentazione rigorosa, gestione dei test tramite repository statici
Prima dell'avvento delle moderne piattaforme di gestione del ciclo di vita delle applicazioni (ALM), la validazione dei sistemi si basava su una massiccia infrastruttura di documentazione. Questo approccio, sebbene oggi percepito come rigido, garantiva una tracciabilità assoluta e una base di prove essenziale per i progetti critici.
Centralizzazione tramite il documento dell'elenco dei test
Il processo di test tecnico e funzionale è stato gestito da un documento principale: il piano di test. Questo documento non si limitava a elencare le azioni, ma strutturava la progettazione del software per moduli. Ciascun modulo (contabilità, acquisti, gestione delle scorte, ecc.) è stato suddiviso in unità funzionali.
Questa organizzazione forniva una panoramica generale dello stato di salute del progetto. L'elenco fungeva da punto di riferimento centrale, garantendo che nessuna regressione venisse trascurata durante un aggiornamento di versione. Al responsabile dei test veniva richiesto un rigore estremo; ogni riga di questo documento rappresentava un impegno al rispetto delle normative. La mancata tempestiva comunicazione dell'aggiornamento di questo repository invalidava l'intera fase di test di accettazione.
L'anatomia del foglio di prova, uno standard di esecuzione
Ogni voce nell'elenco corrispondeva a una singola scheda di test. Questo livello di dettaglio mirava a eliminare qualsiasi soggettività durante l'esecuzione. La scheda era composta da sezioni immutabili:
- Definizione dei requisiti minimi:Prima di poter intraprendere qualsiasi azione, era necessario soddisfare i requisiti di ammissibilità al test. Questi includevano la disponibilità di un ambiente dedicato, la presenza di specifici set di dati nel database e l'accesso a particolari profili utente. Il mancato rispetto anche di un solo prerequisito invalidava l'intera procedura.
- Lo scenario operativo:Il collaudatore è stato guidato da una serie precisa di istruzioni. La neutralità dello scenario ha garantito che il test producesse lo stesso risultato, indipendentemente da chi lo eseguisse. Questa riproducibilità è il fondamento del metodo scientifico applicato all'informatica.
- Il risultato atteso:Questa sezione definiva la verità di base. Il comportamento del sistema doveva corrispondere punto per punto a questa descrizione. Qualsiasi deviazione doveva essere registrata.
Il fattore umano e l'organizzazione del team
Il metodo tradizionale si basava su una rigida separazione dei ruoli. Un team di test dedicato, spesso separato dal team di sviluppo, era responsabile dell'esecuzione. Questa indipendenza garantiva l'imparzialità dei test.
Il processo di tracciamento era manuale e dispendioso in termini di tempo: per ogni esecuzione era necessario registrare la data, il nome della persona che eseguiva il test e lo stato (Superato, Fallito o Bloccato). In caso di errore, veniva redatta una descrizione tecnica dettagliata. Tale descrizione doveva consentire allo sviluppatore di riprodurre l'anomalia in modo inequivocabile. La comunicazione tra il team di test e gli sviluppatori avveniva tramite questi fogli di tracciamento, creando un ciclo di correzione spesso lungo ma estremamente ben documentato.
La rivoluzione di Azure DevOps, l'industrializzazione del piano di test
Il passaggio ad Azure DevOps trasforma questi documenti statici in oggetti digitali interconnessi. La gestione dei test non è più una fase finale scollegata, ma un flusso continuo integrato nello sviluppo.
Prerequisiti e gestione delle licenze
L'accesso alle funzionalità di test avanzate in Azure DevOps non è disponibile per impostazione predefinita per tutti gli utenti. A differenza delle attività di base (Backlog, Board), la gestione dei piani di test richiede una licenza specifica: la licenzaEPiani di test di Azure.
È generalmente incluso per gli abbonati a Visual Studio Enterprise. Per gli altri, è necessario attivare un'estensione a pagamento a livello di organizzazione. Senza questo diritto di accesso, l'utente può solo visualizzare i risultati o eseguire test molto basilari, ma la creazione e la strutturazione dei piani rimangono inaccessibili.
Strutturazione del piano di test
In DevOps, il piano di test sostituisce il vecchio documento di elenco dei test. Viene creato per un ciclo specifico (uno Sprint o una Release). All'interno di questo piano, diS Suite di prova (Le suite di test) sono organizzate. Ne esistono tre tipi:
- Suite statica:Una cartella classica per organizzare manualmente i test.
- Suite basata su query:Una suite dinamica che raggruppa automaticamente tutti i test che soddisfano un determinato criterio.
- Suite basata sui requisiti:La soluzione più efficace, che collega direttamente i test a una User Story o a un'esigenza funzionale.
Creazione e configurazione di un caso di test
All'interno di queste suite, i fogli di prova diventanoS Casi di testLa creazione di un caso di test conserva i principi fondamentali del vecchio modulo di test, ma aggiunge interattività:
- Passaggi:Ogni fase dello scenario è descritta con la relativa azione e il risultato atteso.
- Parametri:È possibile inserire variabili per testare lo stesso scenario con diversi set di dati senza moltiplicare i record.
- Passaggi condivisi:Se un processo è comune a diversi test, viene creato una sola volta e condiviso, semplificando la manutenzione.
Esecuzione tramite Web Runner, un'interfaccia di controllo dinamica
L'esecuzione dei test in Azure DevOps avviene tramite unUn'interfaccia dedicata guida l'utente in tempo reale. Il processo inizia dall'unghia.T Eseguiredel pianon di test. Dopo aver selezionato il test o la suite di test pertinenti, l'utente avvia la procedura tramite l'opzione “Eseguire per applicazione web”.
Questa azione apre il Web Runner, una finestra interattiva che si sovrappone all'applicazione in fase di test. Questa interfaccia presenta in sequenza i passaggi definiti durante la progettazione del caso di test:
- Validazione interattiva dei passaggi:Per ogni fase dello scenario, il tester dispone di un sistema di validazione binaria. Un "controllo" positivo viene applicato se il comportamento osservato è corretto. Un indicatore negativo viene utilizzato in caso di discrepanza.
- Documentazione immediata dell'anomalia:Se una fase non va a buon fine, l'interfaccia consente di generare immediatamente una segnalazione di bug. Utilizzando il pulsante di creazione del bug integrato nel runner, il sistema precompila il ticket con le fasi già completate, i risultati attesi e le discrepanze riscontrate.
- Acquisizione di prove multimediali:Web Runner offre strumenti nativi per documentare visivamente i malfunzionamenti:[BL]
- Screenshot:Un pulsante dedicato consente di scattare istantanee di errori di visualizzazione o messaggi di sistema.
- Registrazione video:La funzione di registrazione dello schermo consente di filmare una sequenza di azioni; questo è un grande vantaggio per riprodurre bug intermittenti.
- Commenti e allegati:Ad ogni passaggio, l'utente può aggiungere note contestuali o allegare file di registro.[IMG:img_1777306097887_4.png;Esecuzione di un test manualmente][IMG:img_1777306097887_4.png;Esecuzione di un test manualmente]
Visibilità e sfruttamento dei risultati
Una volta chiusa la sessione di esecuzione, i dati vengono immediatamente aggregati a livello di piano di test. La visibilità è completa e istantanea.
- Cruscotti di avanzamento:Lo stato generale del piano viene aggiornato in tempo reale.
- Tracciabilità end-to-end:È possibile risalire all'origine di un bug, individuando il test specifico che lo ha generato.
- Cronologia di esecuzione:Ogni esecuzione viene archiviata con il suo contesto completo. I risultati dello stesso test possono essere confrontati tra diverse versioni del software.
Dashboard di monitoraggio
Conclusione
Il passaggio da una gestione documentale rigorosa a una gestione integrata nell'ambito del DevOps non elimina la necessità di rigore; si limita a spostarla. La precisione un tempo dedicata alla compilazione di moduli cartacei viene ora impiegata nella configurazione di piani di test dinamici. Questa transizione riduce drasticamente il tempo che intercorre tra la scoperta di un errore e la sua risoluzione, preservando al contempo l'eredità metodologica dei test basati su moduli.