Qual è il miglior servizio Android QA?

Ho lavorato come SDET mobile per gli ultimi 2 anni prima a Urbanspoon e a GoDaddy (azienda) lavorando sulla loro automazione e test di app iOS e Android. Queste aziende non sono affatto piccole o startup, ma i nostri team sono piuttosto piccoli, quindi queste pratiche dovrebbero applicarsi.

1. Il test delle app mobili è difficile, costoso, richiede tempo ed è soggetto a errori. Una soluzione non va bene per tutti.
   
2. Ci sono molte soluzioni, prodotti là fuori per l'automazione, sceglierne uno richiede tempo e sperimentazione. Per i frameworks avete Appium, Robotium, Calabash, espresso, per l'infrastruttura avete macchine locali, dispositivi reali, emulatori, per i cloud provider - sauce labs, testdroid, perfecto etc, per CI jenkins, iOS CI server etc.
   
3. Il 95% dei bug funzionali possono essere trovati su emulatori/simulatori, ma alcuni no.
4. La strumentazione delle vostre app è molto importante - una volta in produzione non avete controllo o visibilità sull'uso e sui problemi che i vostri utenti stanno affrontando. Avere qualcosa per i crash - crashlytics, crittercism etc, qualcosa per l'utilizzo - GA, strumenti interni.
5. L'80% dei bug di produzione avviene nei livelli API e sono intermittenti. Usa qualcosa come Runscope per monitorare la salute delle tue api.
6. L'automazione non può sostituire i test esplorativi/manuali. L'atto di toccare un dispositivo, nel contesto di altre app è molto diverso dall'automazione. Pensate all'automazione come a uno strumento che libererà il vostro tempo per fare test più utili.
   

Consigli specifici per l'automazione mobile:

1. Mocking è inesistente (non popolare) nei livelli UI per le app mobili, quindi non puoi fare test di integrazione parziale. Inevitabilmente la tua automazione assomiglia molto al fare le stesse azioni più e più volte. es: per ottenere la schermata dei filtri devi caricare l'app -> fare la tua ricerca -> cliccare su filtri -> aspettare la schermata dei filtri-> poi fare il tuo test.
2. La scelta del linguaggio per l'automazione non deve essere la stessa della piattaforma di sviluppo ma i test dovrebbero essere attivabili facilmente. Ad esempio: io uso ruby per automatizzare Android (java) e Ios (objc/swift) ma fornisco un modo a linea di comando per invocare i test
3. Sapete per chi state astraendo l'automazione. Nel mio primo progetto ho fatto l'errore di portare l'astrazione troppo in alto: test cucumber -> definizioni di step -> oggetti Page -> localizzatori specifici del dispositivo. Alla fine ero l'unico consumatore e ha finito per fare più manutenzione ad ogni livello senza molti benefici.
4. L'esecuzione programmata dei test è importante. Si dovrebbe avere un piano per mettere i test di automazione in esecuzione programmata prima che le app arrivino negli app store.
   

E per favore non chiamateci QA. Siamo sviluppatori d'élite che si concentrano solo sulla qualità.