Attività, benefici e rischi dell’automazione dei test software 

Attività, benefici e rischi dell’automazione dei test software 

Il software testing

L’attività di testing è una delle fasi fondamentali appartenenti al ciclo di vita di un software, ed ha come scopo quello di elevarne la qualità e verificare che il comportamento sia il più in linea possibile con quanto richiesto. Il superamento di tutti i test non garantisce che il software, una volta rilasciato, funzionerà come dovrebbe, ma è utile per ridurne la difettosità.

Un’errata percezione comune del testing è che consista solo nell’esecuzione di test, cioè nell’esecuzione del software e nel controllo dei risultati. Tuttavia questo processo include molte attività differenti, e quella appena citata è solo una di queste. Altre sono la pianificazione, l’analisi, la progettazione e l’implementazione dei test, il controllo dell’avanzamento e i risultati, e la valutazione della loro qualità.

Alcuni test richiedono l’esecuzione del componente o del sistema in fase di test: questo tipo di testing è detto dinamico. Altri invece consistono in un’analisi preliminare del codice, senza la necessità di eseguirlo: questo tipo di testing è invece statico.

Un’altra credenza sbagliata è quella che prevede che il testing si concentri interamente sulla verifica dei requisiti, delle user stories o altre specifiche, ma questa è solo una delle sue principali attività. Il testing comprende anche la validazione, ovvero la verifica che il sistema soddisfi sia i bisogni dell’utente sia degli altri stakeholders nel proprio ambiente operativo.

Al giorno d’oggi, qualsiasi tipo di software viene realizzato in team, questo significa che è necessaria una costante comunicazione tra tutti i suoi membri, ogni qualvolta viene apportata una modifica. Per evitare che delle modifiche successive compromettano delle funzionalità già precedentemente testate e funzionanti, si ricorre al Regression Testing che consiste nella ri-esecuzione, totale o parziale, dei test precedentemente scritti, per assicurarsi che i cambiamenti più recenti non abbiano introdotto nuovi bugs (in caso contrario siamo appunto in presenza di una regressione).

Essendo quella del Regression Testing una tipologia di testing che può richiedere molto tempo, è diventato sempre più comune il processo di automazione della stessa all’interno del contesto di Continuous Integration e Continuous Delivery . Entrambi i concetti si traducono nella creazione di una pipeline che prima esegue i test sulle nuove funzionalità, e solo in seguito al loro superamento, è in grado di integrarle all’interno dell’applicazione.

Componenti chiave di questo concetto sono i test automatici. E’ necessario quindi, a tale scopo, scrivere degli opportuni script di test, ovvero un insieme di istruzioni che vengono eseguite sul sistema, per verificarne il corretto comportamento. La corretta scrittura di questi test permette di risparmiare sia tempo che risorse, nel momento in cui il sistema cambia, in seguito ad una modifica, e uno o più test falliscono. In questo modo sarà più semplice per lo sviluppatore, risolvere il problema o, perlomeno, identificarne la fonte di provenienza. Questa fase può essere molto critica, in quanto le correzioni effettuate a seguito di un test non funzionante, potrebbero causare il fallimento di un test che invece prima non dava problemi. A tal proposito, i test di regressione possono quindi diventare una componente considerevole del progetto, in termine di righe di codice.

Attività, benefici e rischi dell'automazione dei test software 

Benefici e rischi dell’automazione dei test software

Ogni nuovo tool introdotto in un’organizzazione richiede uno sforzo per ottenere benefici reali e duraturi. L’utilizzo di tools per eseguire i test comporta potenziali vantaggi e opportunità, ma ci sono anche rischi. I potenziali vantaggi dell’utilizzo di strumenti a supporto dell’esecuzione dei test includono:

  • Riduzione del lavoro manuale ripetitivo (ad esempio: esecuzione di test di regressione, creazione e distruzione dell’ambiente di testing, inserendo nuovamente gli stessi dati di prova e controllando gli standard di codifica), che si traduce in un risparmio in termini di tempo.
  • Maggiore coerenza e ripetibilità (ad esempio: i dati dei test sono creati in modo coerente, i test sono eseguiti da uno strumento nello stesso ordine con la stessa frequenza, e i test sono costantemente basati sui requisiti).
  • Valutazione più obiettiva (ad esempio: misure statiche, coverage).
  • Più facile accesso alle informazioni sui test (ad esempio: statistiche e grafici sui progressi dei test, sui tassi di difettosità e sulle prestazioni).

Ci sono anche una serie di rischi:

  • Le aspettative per lo strumento possono essere irrealistiche (inclusa la funzionalità e la facilità d’uso).
  • Il tempo, il costo e l’impegno per l’introduzione iniziale di uno strumento possono essere sottovalutati (compresa la formazione e le competenze esterne).
  • Il tempo e l’impegno necessari per ottenere benefici significativi e continui dallo strumento possono essere sottovalutati (compresa la necessità di modificare il processo di prova e di migliorare continuamente il modo in cui lo strumento viene utilizzato).
  • Si tende a fare troppo affidamento sul tool (visto come un sostituto per la progettazione o l’esecuzione del test, o l’uso di test automatizzati dove il test manuale sarebbe migliore).
  • Il fornitore dello strumento può cessare l’attività, ritirare lo strumento o vendere lo strumento a un altro fornitore.
  • Il fornitore può fornire una risposta inadeguata per il supporto, gli aggiornamenti e la correzione dei difetti.
  • Un progetto open source può essere sospeso.
  • Una nuova piattaforma o tecnologia potrebbe non essere supportata dallo strumento.
  • Potrebbe non esserci una chiara proprietà dello strumento (ad esempio, per il tutoraggio/formazione, gli aggiornamenti, la compatibilità, ecc.).

I diversi tipi di test

Per quanto riguarda i test automatici si distinguono diverse tipologie:

  1. Test unitari: sono quelli di livello più basso. Consistono nel test di singoli metodi e funzioni delle classi, dei componenti o dei moduli utilizzati dal software, isolati dal sistema di cui fanno parte. Per fare ciò vengono spesso utilizzati i test doubles, che permettono di testare il comportamento dell’unità in reazione a specifici stimoli, al fine di verificare che corrisponda a quello previsto.
  2. Test di integrazione: verificano che i diversi moduli o servizi utilizzati dall’applicazione funzionino bene insieme. Ad esempio, si può testare l’interazione con il database o assicurarsi che i microservizi funzionino insieme come preQuesti tipi di test sono più costosi da eseguire in quanto richiedono l’esecuzione di più parti dell’applicazione.
  3. Test funzionali: si concentrano sui requisiti di business di un’applicazione. Verificano solo l’output di un’azione e non controllano gli stati intermedi del sistema durante l’esecuzione di tali test.
  4. Test end-to-end: replicano il comportamento di un utente con il software in un ambiente applicativo completo e permettono di verificare che diversi scenari funzionino come previsto. Questi possono essere semplici come il login all’interno di una pagina Web o molto più complessi come la ricezione di notifiche tramite email, pagamenti online e così via.
  5. Test di accettazione: sono test formali eseguiti per verificare se un sistema soddisfa i requisiti di business, infatti richiedono che l’intera applicazione sia Si focalizzano maggiormente sulle funzionalità più sollecitate da parte degli utenti e/o quelle con più alto valore di business. Possono anche andare oltre e misurare le prestazioni del sistema, ed eventualmente non approvare le modifiche se determinati obiettivi non vengono raggiunti.
  6. Test di performance: Verificano i comportamenti del sistema quando è sotto Questi test non sono funzionali e possono essere eseguiti in vari modi per stabilire l’affidabilità, la stabilità e la disponibilità della piattaforma. Ad esempio, si possono osservare i tempi di risposta durante l’esecuzione di un numero elevato di richieste, o vedere come il sistema si comporta con una quantità significativa di dati.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *