Che cos’è la Mobile Testing Challenge e testing di applicazioni mobile

Mobile Testing Challenge

La capillare diffusione di smartphone e device portatili di varia natura ha fatto sì che un gran numero di software house migrassero la loro produzione dai software desktop a quelli mobile. L’esportazione dei processi di sviluppo tradizionali non si è dimostrata abbastanza flessibile da reggere i velocissimi cambiamenti del settore e spesso le aziende si sono trovate a fronteggiare una complessa fase di ristrutturazione dei processi e di training del personale per adeguarsi alle nuove necessità.

Allo stesso tempo un esercito di programmatori autodidatti e di professionisti in cerca di fortuna hanno anch’essi intrapreso la strada del mobile speranzosi di poter accedere, con la giusta dose di intuizione e fortuna, agli enormi profitti che questo mercato sta garantendo.

Anche in questo caso, un approccio spesso destrutturato e privo delle più elementari best practices, ha contribuito ad alimentare il vasto panorama di applicazioni più o meno bacate e di poco successo che affollano i vari market.

Si è dunque presto fatta sentire l’esigenza di individuare e formalizzare una serie di strategie e framework per lo sviluppo di applicazioni mobile, arrivando alla conclusione che oltre il 50% dell’effort dovrebbe essere destinato alla fase di testing per produrre software di valore e di successo.

Poiché progettare, realizzare e manutenere test suite oltre ad essere un’attività estremamente dispendiosa è sempre stata considerata tediosa e spesso trascurata dagli sviluppatori, specialmente nei contesti aziendali più piccoli, i tools per l’automazione e la semplificazione della stesura/esecuzione dei test hanno riscosso sempre maggior successo.

La sfida del mobile

Rispetto al mondo del software desktop e di quello web il panorama mobile è estremamente più eterogeneo. Dal punto di vista commerciale questa è un’opportunità interessante per aumentare la clientela diffondendo il proprio prodotto in altri paesi e su tanti dispositivi, dal punto di vista tecnico, invece, doversi confrontare con una moltitudine di device diversi per hardware e software è una sfida complessa che può essere gestita soltanto con un’elevata copertura dei casi di test. I seguenti punti analizzano e discutono ciascuna delle criticità insite nello sviluppo e quindi nel testing di applicazioni mobile.

Varietà dell’hardware

Fatta eccezione per il mondo Apple che offre al mercato una ridotta gamma di dispositivi, il panorama Android e Windows è estremamente variegato.

Oltre alle differenze banali tra produttori e modelli è necessario tenere in considerazione che spesso non sono solo gli smartphone ad utilizzare le applicazioni realizzate ma anche una vasta gamma di prodotti di nuova generazione tra cui tablet, smartwatches, smart tv e oggetti di domotica.

Ciascuno ha inoltre una dotazione in termini di interfacce e sensori che potrebbe differire dai modelli simili introducendo un ulteriore livello di complessità.

Le api messe a disposizione non garantiscono una compatibilità con tutto l’hardware su cui l’applicazione potrebbe trovarsi a girare, d’altra parte è pressoché impossibile testare e quindi garantire il funzionamento su tutto. Altro aspetto non banale legato all’hardware è quello delle prestazioni direttamente correlate alla disponibilità di CPU e memoria.

Varietà del software

Se l’hardware è un problema importante da considerare quello del software lo è ancora di più. I principali sistemi operativi mobile in commercio hanno piattaforme di sviluppo completamente differenti tra loro e sebbene esistano dei tool in grado di operare la conversione di un’applicazione sviluppata in un linguaggio specifico in questa sede non prenderemo in considerazione i problemi legati allo sviluppo per differenti SO.

Come sempre il migliore caso di studio è Android che è presente sul mercato su migliaia di diversi dispositivi con una grandissima varietà di major e minor releases come mostrato dalla tabella sottostante.

Ciascuna versione di Android, contraddistinta da un API Level, aggiunge e sottrae qualcosa alla precedente rendendo per gli sviluppatori molto difficile sfruttare le ultime potenzialità offerte continuando a conservare la retrocompatibilità.

Supportare anche versioni meno recenti del SO dà accesso ad una fetta più ampia di mercato, test script realizzati ad hoc possono garantire che nel corso del suo ciclo di vita il software mantenga la backword compatibility desiderata.

Anche nel caso in cui non sia l’applicazione a modificarsi l’automazione si rivela indispensabile al fine di verificare la robustezza del prodotto in seguito a major e minor release del sistema operativo target.

Differenti operatori di rete

La maggior parte delle applicazioni mobile ha bisogno dell’accesso ad internet per il proprio funzionamento, per salvare dati in cloud o utilizzare servizi web e REST. Nel panorama mondiale convivono ben oltre 400 operatori di rete mobile ciascuno dei quali supporta numerose tecnologie: alcune molto diffuse come LTE, CDMA, GSM, ed altre di minore importanza relative a standard locali come iDEN, FOMA, e TD-SCDMA.

Il punto critico in questa infrastruttura è il passaggio da una rete packet-based come quella cellulare a quella web basata sul protocollo TCP-IP. Questo tunneling è effettuato in modo diverso da ogni operatore. Inoltre spesso gli operatori utilizzano proxy e filtri per limitare particolari categorie di traffico o applicazioni particolarmente band consuming. Non è insolito inoltre che sul traffico web venga effettuato un pre-scaling per ridurre la dimensione dei dati ricevuti, specialmente nel caso di video o immagini che vengono adattati a dimensioni più consone a display mobili. Purtroppo le reti cellulari non sono molto potenti, hanno copertura limitata e quindi, per testare la connettività attraverso un particolare operatore, bisogna trovarsi nella zona dove risiedono le sue celle.

Naturalmente è impensabile viaggiare in ogni nazione per verificare la compatibilità degli operatori di rete locali e bisogna accettare un compromesso.

Testare su reti Wi-Fi è semplice, economico ed accettabile nelle prime fasi dello sviluppo ma esistono anche dei tools per la simulazione di reti usando connessioni WAN/Wi-Fi. Questi strumenti si rivelano preziosi specialmente per simulare le varie ampiezze di banda (es. 2G, 3G, and 4G) e quindi le prestazioni dell’applicazione in differenti scenari.

Native, hybrid e web application

Le applicazioni per smartphone possono essere realizzate in tre diverse modalità, applicazioni native, applicazioni web mobile e ibride. Di seguito considereremo brevemente i pro e i contro di ciascuna.

Le applicazioni native sono quelle che è possibile scaricare abitualmente dai market online e che risiedono stabilmente nella memoria del device. Sono progettate e realizzate per una specifica categoria di dispositivi e pertanto possono sfruttarne tutte le potenzialità in termini di performance, widget e gestures offerti dalle API, sensori e interfacce. Nel caso Android in particolare la volontà di utilizzare le risorse dell’hardware ospite vengono esplicitamente dichiarate ed accettate dall’utente in fase di installazione garantendo quindi all’applicazione il permesso di operare.

Dal punto di vista commerciale con le applicazioni native è possibile fidelizzare il cliente attirandone l’attenzione con notifiche e aggiornamenti.

Il principale svantaggio è che le applicazioni native soffrono maggiormente del device challenge e risulta molto oneroso il loro porting da una piattaforma all’altra. Infatti i più diffusi sistemi operativi mobile, Apple e Android, differiscono tra loro anche per il linguaggio di programmazione utilizzato. Per quanto riguarda il testing di applicazioni native bisogna considerare che il ciclo di vita del software comprende oltre all’esercizio anche l’installazione ed un certo numero di aggiornamenti che vanno adeguatamente previsti e testati.

Le applicazioni web non sono altro che versioni ottimizzate per il mobile di web applications spesso già esistenti accessibili dal browser.

Il loro sviluppo è molto economico perché richiede l’utilizzo di tecnologie molto comuni ed in breve tempo è possibile realizzare un’applicazione cross-platform e cross-device. Tuttavia la semplicità di realizzazione non è in grado di ripagare una serie di svantaggi, tra cui il fatto che una web application necessita della connessione ad Internet, ha un ridotto numero di funzionalità e può interagire con l’hardware del device in modo limitato. Inoltre le connessioni degli utenti non sempre hanno velocità sufficienti a garantire una buona user experience in applicazioni che utilizzano massicciamente linguaggi lato client come javascript e che quindi richiedono ad ogni accesso il download di librerie e script degradando le prestazioni del device. Non ultimo è da considerare il ben noto problema della cross compatibility tra browser.

Dal punto di vista commerciale le applicazioni web non risiedendo sul device devono esplicitamente essere cercate e memorizzate dall’utente e sfuggono all’enorme bacino di utenza convogliato dai market.

Un punto di incontro tra queste due tecnologie sono le applicazioni ibride, esse seguono il ciclo di installazione/aggiornamento/disinstallazione di una comune app nativa ma la maggior parte delle funzionalità è realizzata con linguaggi web e visualizzata attraverso il browser. In tal modo i costi del porting sono estremamente ridotti e spesso addirittura azzerati grazie alla disponibilità di tools ad hoc.

Interruzioni

Non bisogna trascurare il fatto che mentre un’applicazione è in esecuzione su un device potrebbe essere interrotta da un processo a più elevata priorità. Nel caso più ovvio per gli smartphone la ricezione di una telefonata o di un SMS potrebbero provocare la sospensione del normale flusso di esecuzione, altrettanto improvviso potrebbe essere il collegamento di un cavo USB o la segnalazione di una ridotta percentuale di batteria. La criticità in questo caso risiede nel prevedere adeguati meccanismi di recovering per garantire una corretta ripresa del funzionamento.

Tutti i sensori e le interfacce del device costituiscono una possibile fonte di interruzione da gestire correttamente.

Orientamento e configurazioni

L’utente è padrone del proprio device e può decidere arbitrariamente di attivare o disattivare funzionalità, di crittografare i dati, di consentire o vietare determinati tipi di accessi ai sensori e alla rete. Un’applicazione robusta deve tener conto delle infinite combinazioni possibili e non può farlo se non generando automaticamente in modo casuale una serie di test case sufficienti a coprire il maggior numero possibile di differenti comportamenti. In questa categoria può essere inserito uno dei principali e più diffusi errori di sviluppo grafici e cioè la gestione del cambio di orientamento da portrait a landscape e viceversa.

Localizzazione

Oltre alle succitate differenze nella rete cellulare la diffusione di un’applicazione all’esterno del paese di origine ha anche altri risvolti nello sviluppo. I più banali punti di attenzione in questo caso è la verifica di fusi orari, unità di misura, charset e valuta.