Testare un'app su Android o iOS non è poi così differente. Lo scopo è lo stesso, il risultato desiderato è lo stesso e il processo è simile. La grande differenza arriva quando iniziamo a guardare i dettagli. Questo è quello che ho intenzione di fare in questo articolo.
Prima di immergerci, parliamo di alcuni test fondamentali. È impossibile rivedere le nostre opzioni a meno che non conosciamo e comprendiamo l'immagine completa.
Ciò che distingue Android è la miriade di possibilità. Su iOS, ci sono iPhone, iPad e iPod Touch. Sono diversi, ma il fattore comune tra i dispositivi iOS è la densità dei pixel, la risoluzione dello schermo, la velocità del processore, la dimensione della memoria, ecc.
Nel caso di Android, ci sono migliaia di combinazioni quando guardiamo quegli stessi fattori, la risoluzione e le dimensioni dello schermo, la velocità del processore, la dimensione della memoria e, la ciliegina sulla torta, la frammentazione del sistema operativo.
Parlando di versioni del sistema operativo, non è raro che i produttori di telefoni e telefoni smettano di spingere fuori gli aggiornamenti non troppo tempo dopo il rilascio del prodotto. È un problema? Sì. Dai un'occhiata alle statistiche ufficiali sulla quota di mercato Android di Google per avere un'idea delle dimensioni del problema.
In ordine decrescente di quota di mercato, abbiamo Jelly Bean (4.1-4.3), Gingerbread (2.3) e Ice Cream Sandwich (4.0).
Confrontalo con il tasso di adozione di Apple iOS 7. Alla fine di gennaio di quest'anno, l'80% dei dispositivi iOS utilizzava iOS 7. Ricorda che iOS 7 è stato rilasciato a settembre 2013. Questa è una grande differenza.
Hai mai usato un'applicazione Android davvero pessima? Peggio di una vera e propria cattiva applicazione è davvero eccezionale con alcuni bug persistenti.
Sento che un fattore importante nella buona sperimentazione è prestare attenzione a ciò che si utilizza, come e l'odio. L'odio è una parola forte, ma sono sicuro che c'è qualcosa che spicca sempre.
Porsi le seguenti domande:
Facciamo riferimento al grafico delle quote di mercato del sistema operativo Android che abbiamo visto in precedenza. Non è realistico avvicinarsi ai test pensando di supportare tutti i dispositivi e tutti i gusti di Android.
Il mio punto è che dobbiamo pensare alla distribuzione. Che cosa fa la nostra app e che aspetto ha il mercato target? È un gioco o un'applicazione di utilità?
Se si tratta di un gioco, l'attenzione potrebbe essere probabilmente solo su dispositivi più recenti e di fascia più alta. Un'applicazione di utilità, tuttavia, potrebbe essere utilizzata da un pubblico più ampio e deve funzionare su una più ampia gamma di dispositivi.
Un problema che sento maggiormente di noi è che siamo troppo vicini ai nostri progetti. Sappiamo come possiamo far fallire la nostra app e come farla funzionare. Per questo motivo, cerco intenzionalmente di mettere la mia mente in quella di un utente. Metto gli utenti in due grandi categorie, il Botton Masher e il Utente.
Button Masher è il tipo di utente che inizierà a toccare lo schermo, un pulsante qui, un pulsante lì. "Quell'ultimo pulsante non ha fatto nulla, ne colpirò un altro."
Quello che possiamo imparare da questo tipo di utente è dove abbiamo processi intensivi all'interno della nostra app. Se qualcosa sta accadendo e si verifica un'altra richiesta o azione, aumentiamo il picco del processore o riempiamo la memoria del dispositivo? Fa arrestare l'applicazione?
L'altra domanda che emerge è "Quanto bene informiamo l'utente di ciò che sta accadendo". Perché hanno colpito un altro pulsante invece di aspettare? Possiamo rimediare mostrando una schermata di caricamento?
L'utente ha intenzione. Un modo migliore per spiegare questo tipo di utente sarebbe quello di esaminare i casi d'uso. C'è un compito specifico che vogliono raggiungere e un flusso specifico che cercheranno di seguire.
Possiamo imparare quanto è chiara l'app per guidare una persona attraverso un processo o un'azione. Ci mostrerà dove un utente si perde e quali aree richiedono più attenzione o raffinazione.
Abbiamo parlato attraverso il nostro scopo e diversi tipi di utenti, ma cosa siamo le nostre opzioni e come dovremmo testarle? Per fortuna, ci sono molte cose. E ti consiglio di farne il maggior numero possibile.
Se non hai il lusso di poterti accompagnare nel reparto di controllo qualità o in un laboratorio di test, puoi chiamare un amico. Hai bisogno di occhi e hai bisogno di dispositivi.
Quando si tratta di testare le app mobili, il volume può fare la differenza, specialmente se è possibile ottenere una varietà di dispositivi.
Il test automatico è tuo amico. Sebbene nulla possa battere il tempo stringe con un'applicazione completa, è anche importante vedere cosa sta succedendo sotto il cofano e come la tua app reagirà in modo programmatico a determinate situazioni o quando messa sotto stress.
Ancora più importante, il test unitario ti consente di eseguire il test man mano che procedi, il che può far risparmiare molto tempo durante i test e il controllo qualità, prima del rilascio.
L'SDK di Android viene fornito con il framework di test di Android, che consiste in un'API di test basata su JUnit e monkeyrunner.
L'estensione Android JUnit consente agli sviluppatori di scrivere test unitari contro componenti Android e l'API Android con classi di test case precompilate specifiche.
Monkeyrunner è un'API basata su Python che consente di scrivere programmi che controllano un dispositivo dal punto di vista dell'utente. Ciò significa che puoi creare test da eseguire su numerosi dispositivi o emulatori che interagiranno con la tua app, inviandoli sequenze di tasti e acquisendo schermate.
Sono disponibili molti framework di test. Alcuni dei più popolari sono Robolectric e Robotium.
Robolectric è un framework di test unitario che viene eseguito nel tuo IDE. Questo è ottimo per il controllo del pre-build del codice. Robotium esegue test contro l'API di Android in emulatori. Mentre ci vuole più tempo per completare i test, il tuo codice applicativo verrà sottoposto a molto più di un test del mondo reale contro i dispositivi e l'API.
Un'altra opzione interessante è l'Espresso. Ha uno scopo ben preciso rispetto alle due precedenti opzioni. È un'API per eseguire test contro l'interfaccia utente Android.
Tutte le opzioni di cui sopra sono fantastiche, ma se stai costruendo un'app ibrida, potresti non essere in grado di usarle. Appium è un framework di automazione multipiattaforma che ti consente di creare test con qualsiasi linguaggio tu voglia per entrambe le principali piattaforme mobili.
È anche molto utile essere in grado di vedere alcune statistiche e, cosa più importante, raccogliere i registri degli errori e degli arresti anomali. Questo è particolarmente utile se hai molte persone che testano la tua applicazione, perché può diventare ingombrante raccogliere i log da ogni singolo utente.
Oltre al monitoraggio dell'utilizzo delle app, Google Analytics può anche inviarti eccezioni. Flurry è un'altra opzione testata. Sono in circolazione da molto tempo e i loro rapporti e rapporti sugli arresti anomali sono un po 'più dettagliati.
Anche se non aiuta durante la fase di sviluppo della tua applicazione, Google raccoglie anche i rapporti sugli arresti anomali per le app nel Play Store.
Tutti vorremmo avere 400 dispositivi da testare, come quei massicci laboratori di test che abbiamo visto online. Tuttavia, ciò non è realistico. Per rispondere a questo problema, ci sono molti servizi disponibili se sei disposto a investire nei test.
Questi servizi spaziano da test "reali su umani" a test completamente automatizzati su centinaia di dispositivi. Se sei disposto a pagare per questo, è disponibile.
Non ho esperienza con la maggior parte di questi, ma quello che ho usato è User Testing. È molto utile vedere una persona seguire lo script di test mentre tocca la tua applicazione e ti fa riflettere.
Questi sono alcuni servizi da considerare:
Troppe volte mi sono imbattuto in situazioni in cui il controllo qualità e i test sembravano un ripensamento. In realtà, è probabilmente la parte più importante del processo di sviluppo.
Android, con i suoi numerosi sapori, può sembrare intimidatorio, ma quando viene avvicinato quasi a livello di programmazione, diventa davvero parte del processo. Vale la pena il tempo e lo sforzo in più. Le app di qualità non si verificano solo.