Ogni livello di test svolge un ruolo specifico nello sviluppo software e risponde a una domanda distinta:
Unit Test - “È cambiata una funzione che doveva restare invariata?” Testano i più piccoli pezzi di codice isolati (singole funzioni o metodi) in modo indipendente dal resto del sistema. (Un'analisi dettagliata degli unit test è trattata in un articolo del blog separato.)
Test di integrazione - “I componenti continuano a funzionare correttamente insieme dopo una modifica?” Testano i collegamenti reali tra i moduli (ad esempio database + livello di servizio + API), non solo funzioni isolate. Fanno emergere scenari in cui le singole parti funzionano da sole ma falliscono quando vengono combinate.
Test E2E (End-to-End) - “Il sistema funziona come lo vivrebbe un utente reale?” Simulano flussi utente completi (login → azione → risultato) attraverso la vera UI o API. Intercettano regressioni che né gli unit test né i test di integrazione riescono a rilevare, perché questi problemi emergono solo all'interno di un flusso reale.
(Esistono naturalmente altri tipi di test, come gli *Smoke test**, i test di carico o i test di sicurezza, che esulano dallo scopo di questo articolo.)*
Tutti i livelli di test automatizzati condividono un obiettivo comune: verificare che le funzionalità non si siano rotte al di fuori dell'ambito del task su cui si sta lavorando. Un task può essere completato alla perfezione secondo le specifiche e rompere comunque qualcos'altro come effetto collaterale involontario. Senza un livello di test che vada oltre la specifica modifica, nessuno se ne accorgerebbe finché un utente non segnala il problema in produzione.
Il ruolo essenziale dei test manuali
Nonostante l'automazione avanzata e l'integrazione dell'AI, i test manuali mantengono il loro ruolo indispensabile e primario. Un tester umano porta giudizio reale, intuizione e la capacità di cogliere sfumature sottili o comportamenti inattesi della UI che gli script automatici si lasciano facilmente sfuggire. La verifica manuale è stata, è e sarà sempre ciò che dà al team di sviluppo la certezza al 100% che l'applicazione sia pronta per gli utenti reali.
Sviluppo assistito dall'AI e compensazione della "cecità"
Nell'era dello sviluppo assistito dall'AI, un livello di test automatizzati è ancora più critico. Un agente AI non può percepire l'intero sistema in una sola volta, e questo rende gli effetti collaterali più probabili rispetto a uno sviluppatore umano, che porta con sé l'intero contesto e la storia delle decisioni passate. I test servono come meccanismo per compensare sistematicamente questa cecità sul sistema prima che il codice arrivi all'approvazione umana finale.
Impatto pratico: le sfide dei test E2E con l'AI
Creare test E2E è particolarmente complesso per l'AI. Non si tratta solo di scrivere lo script di test, ma soprattutto di preparare dati di test adeguati in modo che il software possa usarli (spesso solo per una piccola parte del test). Preparare questi dati è molto impegnativo.
Consideriamo un'azione apparentemente semplice: fare clic su un elenco a discesa e selezionare un parametro (ad esempio il tipo di documento Fattura). Se il test fallisce o non si completa, è fondamentale diagnosticarne l'esatta causa. Possono essersi verificate diverse situazioni:
- L'AI si è persa e non è riuscita a trovare l'elemento a discesa nella UI (anche se è presente).
- Il test ha incontrato un errore precedente lungo il percorso e non è riuscito a riprendersi.
- L'elenco a discesa esiste, ma non contiene i dati attesi da selezionare.
- L'AI ha ripiegato su JavaScript (una scorciatoia invisibile), impostando con successo il valore in modo programmatico ma lasciandolo invisibile a un utente reale.
Intorno a un singolo elenco a discesa possono nascere numerosi problemi. Il punto chiave è se l'AI (o il sistema di valutazione) sia in grado di distinguere un vero bug da un fallimento a cascata causato da qualcos'altro. Il semplice fatto che i dati vengano salvati con successo non garantisce che tutto funzioni correttamente.
Approccio comportamentale e copertura dei test
Per questo motivo i test dovrebbero concentrarsi sempre sull'aspetto comportamentale del sistema, testando ciò che ci aspettiamo realmente che accada:
Happy Path (~90% dei casi): l'attenzione principale va a ciò che gli utenti faranno nella stragrande maggioranza dei casi.
Edge case critici: condizioni limite che non si verificano di frequente, ma sono vitali per l'integrità del sistema.
Le altre combinazioni meno probabili non vengono testate in anticipo. Se si verificano in produzione, vengono corrette al volo oppure prevenute tramite vincoli e validazioni del software (ad esempio disabilitando la navigazione finché gli input non sono validi).
Test E2E in AITM
In AITM i test E2E rappresentano una fase obbligatoria della pipeline, esplicita, per i task che hanno impatto sulla UI (stabilito dal tipo/intento del task). Non è un componente aggiuntivo opzionale da saltare quando le scadenze si avvicinano: una pipeline non può essere segnata come completata senza di essa.
Se un test E2E manca o l'ambiente non è disponibile, la build fallisce per impostazione predefinita (con rare eccezioni in cui è consentito proseguire con un E2E fallito). Inoltre ogni esecuzione E2E cattura screenshot visibili nei risultati del task.
Come funziona oggi l'E2E:
- Prima di eseguire i test, la build è garantita come riuscita e viene eseguita nel proprio worktree isolato.
- Lo stato del database viene preparato con dati di test specifici insieme ai record predefiniti.
- I test si concentrano rigorosamente sull'Happy Path (non coprono tutti gli scenari possibili).
Roadmap futura per l'E2E:
- Flow Maps - Il sistema costruisce una mappa dei percorsi verso gli elementi collegati direttamente alla business logic (già integrata in AITM).
- Navigazione autonoma - I test leggono la mappa dei percorsi dal vivo, sapendo con precisione dove fare clic, digitare e verificare (attualmente in fase di test).
- Confronto degli stati (Visual Diffing) - Ogni passo viene registrato con screenshot scattati prima e dopo le modifiche al codice, per confermare che gli elementi e i dati attesi corrispondano alle aspettative del DB o della UI.
- Verifica della Business Logic - Controllo automatico dei dati di output attesi (ad esempio totali di fattura verificati - attualmente in sviluppo).
- Esecuzioni di integrazione notturne - I test di integrazione end-to-end verranno generati automaticamente dagli stati dei passi e dai requisiti software per essere eseguiti durante la notte. Qualsiasi fallimento genererà task o richiederà una verifica umana (perché l'AI può sbagliare e ha bisogno dell'approvazione di una persona).
- Scenari avanzati - Le release future incorporeranno l'iniezione di parametri non validi, test di concorrenza multi-istanza e simulazioni di edge case.
Riepilogo dei principi fondamentali dell'E2E
L'essenza di un test E2E efficace si basa sulla gestione delle mappe e delle relazioni tra le entità di dati. Per il 90% del software si riduce al ciclo di vita standard:
#AITM #Data Input Validation #E2E #Integration test #AI TESTING