Quali sono i tempi del testing e le responsabilità degli sviluppatori software
I tempi del testing software e le responsabilità degli sviluppatori
Per produrre software di qualità non è sufficiente prevedere una fase di testing finale, una volta terminato lo sviluppo i bug emersi potrebbero essere costosissimi in termine di rework. Presto e spesso sono le key word per una test strategy di successo.
E importante che nel processo di quality assurance tutti siano coinvolti, progettisti, sviluppatori e tester fin dai primi stadi dello sviluppo.
Già durante la prima stesura del codice ciascuno sviluppatore può essere in grado di individuare potenziali sorgenti di bug e bad practice da evitare. Grazie ai sempre più sofisticati tool per la Static Code Analysis i bug latenti possono essere individuati fin dai primissimi giorni di vita del software.
La Static Code Analysis non fa altro che leggere il software e analizzare i costrutti per individuare potenziali fonti di malfunzionamento e segnalare gli statement che non rispettano gli standard qualitativi e le guideline. E’ un’attività che spesso viene citata come parte del White Box Testing ed ha lo scopo di individuare le vulnerabilità nel codice sorgente utilizzando tecniche come Taint Analysis and Data Flow Analysis.
Molto spesso questi tool di analisi sono integrati con i principali IDE per fornire feedback immediati allo sviluppatore riguardo la qualità del software prodotto.
Uno dei tool più utilizzati a tal proposito, specialmente nel mondo Android, è Lint.
Grazie a tool come Lint e Sonar oltre all’analisi è possibile estrarre metriche di qualità come la coverage, la percentuale di duplicazioni, l’eccessivo accoppiamento etc.
Test driven developement
Il Test Driven Development (TDD) è un modello di sviluppo del software che prevede che la stesura dei test automatici avvenga prima di quella del software che deve essere sottoposto a test, e che lo sviluppo del software applicativo sia orientato esclusivamente all’obiettivo di passare i test automatici precedentemente predisposti.
Più in dettaglio, il TDD prevede la ripetizione di un breve ciclo di sviluppo in tre fasi, detto “ciclo TDD”. Nella prima fase (detta “fase rossa”), il programmatore scrive un test automatico per la nuova funzione da sviluppare, che deve fallire in quanto la funzione non è stata ancora realizzata. Nella seconda fase (detta “fase verde”), il programmatore sviluppa la quantità minima di codice necessaria per passare il test. Nella terza fase (detta “fase grigia” o di refactoring), il programmatore esegue il refactoring del codice per adeguarlo a determinati standard di qualità.
Continuous Integration
Le applicazioni mobile spesso seguono un ciclo di sviluppo agile contraddistinto da release frequenti con piccoli incrementi delle feature. Un motivo per rilasciare aggiornamenti potrebbe essere trarre beneficio dalle nuove API e dalle nuove versioni del Sistema Operativo, che potrebbero migliorare e/o velocizzare la user experience. Ogni upgrade per quanto minimo richiede un ciclo di test addizionale.
Similmente l’introduzione sul mercato di un nuovo modello di device candidato come top di gamma richiede un’immediata verifica di compatibilità.
Ogni ciclo di test ha un’ampiezza che dipende dalla natura del cambiamento intervenuto, si può passare attraverso i cosidetti “smoke” o “sanity” test per le fix di minor rilievo fino a una suite completa di regression test.
Un processo di sviluppo e rilascio così dinamico deve essere necessariamente strutturato per evitare disorganizzazione e rallentamenti.
La continuous integration è una pratica di gestione del ciclo di vita del software applicata in contesti dove più sviluppatori collaborano, lavorando contemporaneamente sugli stessi file sorgente, e dove sono necessarie frequenti build e release. Con tale tecnica, basata sulla disponibilità di un repository e di un tool per il versioning dei file, più volte al giorno le modifiche rilasciate vengono integrate, compilate, installate e testate in un ciclo continuo che garantisce la rilevazione in tempo reale di eventuali bug di regressione o derivanti dall’integrazione.
Appare evidente quanto questo approccio possa rivelarsi prezioso nel mondo mobile dove è necessario rapidamente rilasciare nuove feature garantendo che le funzionalità preesistenti non siano state intaccate.
Poiché i tool per la CI gestiscono le varie fasi in maniera completamente automatica è necessario che i test siano realizzati sotto forma di script automatici e sottoposti a versioning come tutto il resto del codice. In qualità di sorgenti, gli script di test possono a loro volta essere soggetti ad errori, regressioni e manutenzione che l’integrazione continua permette di individuare e risolvere il prima possibile.
Il più famoso tool opensource per la continuous integration, Jenkins, offre numerosi plugin per l’integrazione con tools e framework di varia natura nonché la possibilità di integrare script batch per l’invocazione di processi custom.
In un ciclo di vita ideale, più volte al giorno il tool aggiorna il sorgente, verifica che non ci siano errori di compilazione e ne opera l’analisi statica. I deliverable prodotti vengono poi installati su una macchina target, eventualmente un emulatore avviato dal tool stesso, ed i test vengono eseguiti. A fine ciclo report accurati vengono prodotti e gli errori segnalati agli sviluppatori responsabili.
Android e il meccanismo di segnalazione
Per quanto tempo e denaro si investa nel testing sarà sempre impossibile rilasciare un software privo di errori, è dunque importante riuscire a raccogliere e risolvere segnalazioni anche quando l’applicazione è già in ambiente di esercizio.
A tal proposito molti market prevedono un meccanismo unificato per il reporting da parte dell’utente di eventuali malfunzionamenti che vengono inoltrati allo sviluppatore.
Dotare la propria applicazione di un logging efficiente è utile sia durante il testing che in fase di produzione per recuperare le informazioni dal device e indirizzare rapidamente la risoluzione del bug.
La Google Play Developer Console è la piattaforma messa a disposizione da Android agli sviluppatori per gestire il ciclo di vita delle applicazioni in vendita su Play Store, questo strumento offre anche la possibilità di vedere i dati raccolti in caso di crash e di errori ANR (Application Not Responding).
In caso di crash all’utente viene richiesto se desidera inviare una segnalazione di errore e gli si offre la possibilità di allegare un messaggio esplicativo. I dati in questi casi saranno disponibili per la consultazione soltanto se l’utente ha scelto di condividerli.
Se, invece, l’applicazione smette di rispondere, all’utente verrà proposto di chiuderla ed i dati raccolti verranno automaticamente inviati agli sviluppatori al fine di facilitare la risoluzione del problema. Sulla console saranno presentate le informazioni come il tipo di errore, la localizzazione, la frequenza con cui si è presentato. Tali report possono poi essere scaricati da Google Cloud Storage in formato CSV.
