Perché iniziare dai flussi di lavoro
La paura di rompere qualcosa è spesso ragionevole. Un campo aggiunto a una schermata può attraversare calcoli, importazioni, documenti e procedure del supporto. Il fatto che la modifica al codice sembri piccola non dice quanto sia ampia la parte di lavoro che ne dipende. Il primo obiettivo del QA Assessment è rendere visibili queste dipendenze, non produrre una percentuale di copertura da esibire.
Partite da un cambiamento reale: per esempio portare online la consultazione degli ordini o collegare un CRM al gestionale. Disegnate i percorsi interessati e chiedete a sviluppo, supporto e utenti quali errori sarebbero più costosi, più frequenti o più difficili da individuare. Così il test riguarda l'effetto sul lavoro, non soltanto le funzioni più semplici da chiamare nel codice.
Cinque flussi esemplificativi da proteggere
Esempio illustrativo: immaginiamo un gestionale che segue ordini, fatture e giacenze. Una prima lista potrebbe essere questa; uso e rischi andrebbero confermati sul prodotto reale. Un flusso raro può essere prioritario se l'errore è grave o emerge troppo tardi. La frequenza da sola non basta.
Conviene annotare anche chi può confermare il risultato atteso: un calcolo che nessuno sa spiegare non diventa corretto solo perché è sempre stato così.
- Creazione ordine — uso quotidiano; proteggere prezzi, sconti e disponibilità; conservare ordine di prova, input e totale atteso.
- Modifica ordine — uso frequente; proteggere ricalcoli e storico; confrontare stato e valori prima e dopo la modifica.
- Emissione documento — uso quotidiano; proteggere numerazione e contenuto; conservare documento e dati che lo hanno generato.
- Importazione listino — uso periodico; proteggere validazioni ed errori; provare un file valido, uno errato e i rispettivi risultati.
- Chiusura mensile — uso raro ma critico; proteggere totali e passaggi irreversibili; usare ambiente di prova, report e controlli manuali.
Registrare una baseline che si possa confrontare
Per ogni scenario scelto servono dati di ingresso, condizioni iniziali, versione del software e risultato osservabile. Non è necessario iniziare da centinaia di casi. Un primo pacchetto potrebbe coprire l'ordine normale, uno sconto al limite consentito, un articolo indisponibile e un utente senza permesso. Se il database contiene dati personali, l'ambiente di prova va preparato con dati adatti al test e accessi controllati.
Il risultato non è sempre un singolo valore restituito da una funzione. Potrebbe essere uno stato nel database, un documento, un messaggio, un evento verso un altro sistema o una combinazione di questi. Registrate anche il comportamento in errore: l'applicazione rifiuta l'operazione, lascia dati parziali o propone una correzione?
I test che catturano il comportamento attuale sono spesso chiamati test di caratterizzazione. Sono preziosi perché segnalano quando una modifica cambia ciò che il prodotto faceva. Ma il comportamento osservato non equivale automaticamente al requisito. Se il gestionale calcola male uno sconto da anni, fissare quel numero come «atteso» potrebbe rendere stabile un difetto. Classificate quindi ogni differenza: regola confermata, comportamento da chiarire, bug noto oppure modifica intenzionale.
Dove mettere i test se il codice è difficile da isolare
Un prodotto legacy può avere funzioni che parlano direttamente con database, file, stampanti o servizi esterni. In questi casi il test unitario non è sempre il primo passo. Si può iniziare da una verifica di integrazione in un ambiente controllato o da un percorso di accettazione eseguito sull'applicazione. Poi si cercano punti in cui separare una dipendenza e rendere più rapido il test successivo.
Michael Feathers definisce questi punti «seams»; Martin Fowler ne mostra l'uso nei test: sono luoghi nei quali si può cambiare il comportamento di una dipendenza senza modificare ogni volta il codice sotto prova. Per esempio, un calcolo che oggi chiama direttamente un servizio esterno potrebbe ricevere in test una risposta prevedibile. La forma concreta dipende dal linguaggio e dall'architettura; forzare un'astrazione ampia solo per far passare il primo test rischia di spostare il problema.
Fonti: Martin Fowler — Legacy Seam
Tenere distinti i livelli di verifica
I test di caratterizzazione, integrazione e accettazione rispondono a domande diverse. La documentazione Microsoft sui test unitari ricorda inoltre che la percentuale di codice coperto non dimostra la qualità dei test. Per un sistema con molta logica nascosta, è più utile sapere quali flussi critici sappiamo verificare e quali restano esposti.
- Test di caratterizzazione: documentano un comportamento esistente che vogliamo sorvegliare.
- Test di integrazione: verificano che componenti, database e interfacce collaborino correttamente.
- Test di accettazione: mostrano a chi usa o commissiona il prodotto che un percorso soddisfa il bisogno concordato.
Confrontare prima e dopo, poi decidere
Eseguite la suite sul prodotto attuale e conservate i risultati. Ripetetela dopo l'intervento nello stesso ambiente o in condizioni equivalenti. Quando compare una differenza, non archiviatela automaticamente come regressione né accettatela perché «il nuovo sistema fa così»: portatela alla persona che conosce la regola di business.
Nelle migrazioni, il confronto di input e output tra vecchio e nuovo sistema è una tecnica esplicitata anche dalla guida AWS per il testing della modernizzazione mainframe. In un gestionale più piccolo il principio si può applicare senza acquistare la stessa infrastruttura: preparare gli stessi casi, eseguirli in modo ripetibile e spiegare le differenze.
Il pacchetto iniziale deve rimanere utilizzabile dal team. Per ogni test servono un nome che descriva il comportamento, dati preparabili di nuovo, un risultato controllabile e un responsabile della regola. Se un test fallisce ogni due giorni per ragioni estranee al codice, smette presto di essere un segnale affidabile. Prima di aggiungerne altri, correggete l'ambiente o isolate la dipendenza instabile.
Il risultato dell'assessment
Alla fine non prometteremmo «software senza bug». Vorremmo una mappa dei flussi critici, una baseline ripetibile, le regole ancora da chiarire e un elenco di rischi per il primo intervento. Questa base rende più sicuro aggiungere un Web Bridge, modificare un modulo o iniziare una migrazione progressiva.
Se oggi ogni rilascio richiede di sperare che tutto continui a funzionare, il QA Assessment è il primo passo pratico. Individuiamo insieme i flussi da proteggere e costruiamo le verifiche utili per affrontare la modifica che hai in programma.