Testear apps en Google Play y App Store
Cuando desarrollamos apps para Android y para iOS, uno de nuestros objetivos es que el cliente pueda testear la app para que pueda ofrecer sus opiniones, su feedback y así poder enriquecer aún más el proceso de desarrollo. Hasta ahora habíamos utilizado métodos tradicionales para el testeo de apps: conseguir el UDID del cliente en el caso de iOS y enviar un .apk al cliente en el caso de Android. Una vez el cliente se ha instalado el certificado generado con su UDID (proceso que podía ser largo y lleno de obstáculos), todo era mucho más ágil y rápido. Aún así, hacía falta que Apple ofreciera un sistema mucho más fácil de testeo de apps.
App Store: cómo hacer testing en TestFlight
Desde la última actualización de iOS (iOS 8), Apple ofrece un nuevo método de testeo: TestFlight. Este servicio ya existía con anterioridad y que Apple adquirió e integró en su sistema de publicación de apps. Con TestFlight podemos tener 25 probadores internos y hasta 1000 probadores externos. Para ser probador interno, el usuario tiene que estar registrado como usuario técnico dentro de la cuenta de iTunes y, por lo tanto, tiene cierto acceso al panel de control de publicación de apps. Por este motivo, sólo podrá ser probador interno alguien de mucha confianza, del propio equipo. En cuanto a los probadores externos: funciona por e-mail (no hace falta que sean usuarios registrados dentro de iTunes Connect) y puede haber hasta 1000. La diferencia entre un tipo de test y el otro, el interno y el externo, es que en el interno no se necesita que Apple revise la app en cuestión y, en cambio, en el externo necesitamos que Apple revise la app. Es decir, que la app pase por un proceso de revisión similar al de cuando publicamos una app. Y sabemos que Apple puede tardar lo suyo en aceptar apps…
En cuanto al testeo interno, ahora mismo hay un bug muy ‘divertido’. Sí, sí… el proceso de envío de apps tanto en Apple como en Google Play está lleno de bugs y de funciones mal diseñadas. Ellos exigen que nuestras apps sean perfectas, pero ellos son los primeros en permitir bugs absurdos, saber de su existencia y no arreglarlos. Uno de ellos es el de cuando invitamos a probadores internos a probar apps. El proceso es el siguiente:
- Registramos el usuario con su ID de App Store en iTunes Connect
- El usuario recibe un e-mail para confirmar el registro y entonces es dado de alta como probador interno
- El usuario tiene que tener instalado TestFlight en su dispositivo
- Enviamos una invitación al usuario para que pruebe la app
Y aquí tenemos el famoso bug absurdo: la invitación (un e-mail) nunca es enviada. Y para poder probar la app, el usuario necesita sí o sí este e-mail. Esto puede suponer la pérdida de horas por parte de quien esté gestionando esto… El caso es que hay una solución laberínticamente tonta. Hay que dar de baja como probadores a los usuarios y después darles de alta de nuevo para poder invitarles de nuevo. Entonces sí funciona. Apple envía el dichoso e-mail. A partir de ahí, los usuarios pueden descargarse la app sin tener que haber instalado ningún certificado en su dispositivo. ¡Perfecto!
Probar las microtransacciones
Por cierto, probar las apps antes de que se publiquen tiene más funciones a parte de las de obtener feedback de clientes y betatesters. Una de las funciones puede ser probar microtransacciones antes de poner a la venta una app. Para ello tendremos que crear un usuario técnico en iTunes Connect (como el que creamos para que pueda ser probador interno) e, inmediatamente, este usuario podrá iniciar sesión en la app y fingir que está comprando algo. De esta manera, podremos saber si todo funciona correctamente. Puede parecer obvio, pero es mejor probarlo todo antes de publicar una app.
Google Play: hacer testing en Alpha y en Beta
En Google Play tenemos un servicio similar de testing. Se trata de poder hacer testing en dos fases diferentes de desarrollo: alpha y beta. Google Play nos permite poder subir el .apk y .obb, si es el caso, de nuestra app y publicarla en modo alpha o beta para poder hacer testeo. Sí, tenemos que publicar la app: esto significa tener ya toda la información: iconos, descripción, capturas de pantalla… Lo que se me ocurre es que si estamos al principio del desarrollo de una app podemos usar este sistema en modo “test total” con imágenes en blanco (por decir algo) en iconos, capturas de pantalla, etc. y con un bundle identifier diferente al definitivo y así podemos usar este sistema para que los clientes y testers puedan bajarse la app sin tener que instalar un .apk. Eso sí, los clientes/testers tendrán que formar parte de un grupo de Google+ (uno creado por nosotros) y, por lo tanto, tendrán que tener una cuenta en Google y en Google+.
De todos modos, no es todo así de fácil y ágil como suena. Primero: cuando publicamos una app, pueden pasar horas hasta que Google no se da cuenta de que está ahí (es decir, hasta que no se ha propagado por sus servidores). Cuando pasan horas… muchas veces los usuarios siguen sin poder bajarse la app, les sale un mensaje de “Elemento no encontrado”. Esto es así porque, según parece, cada vez que un usuario diferente intenta acceder a una app, Google tarda un rato en hacer disponible esa app para el usuario. Este rato es de horas… incluso 3 horas. Esto significa que si lo que pretendemos es ir haciendo pruebas diarias como hemos llegado a hacer en Ubicuo Studio (en el desarrollo del videojuego La Pegatina o el videojuego Pica Lletres), este sistema no nos funcionará. Por su lentitud. Y tendremos que hacerlo por el método tradicional del envío del .apk. ¿Qué pasa cuando enviamos .apks? Que os exponemos a cierta piratería, porque enviar un .apk implica no certificar para nada la app y, por lo tanto, esta queda libre de ser instalada en cualquier dispositivo. Ya podéis imaginar que esto en según qué desarrollos no se puede permitir… Por eso tendremos que “pasar por el aro” de esperar horas hasta que Google se decide a ir más rápido en hacer disponibles las apps en modo alpha y beta.
