Pruebas cerradas de Google Play: lo que aprendimos creando Kleos Music

Hace un mes empezamos a construir Kleos Music con una idea bastante sencilla: un reproductor de música local no debería sentirse como una versión inferior de una aplicación de streaming.

Queríamos que la música que ya tienes en tu teléfono pudiera sentirse completa. Letras, portadas, metadatos, widgets, notificaciones y búsqueda, sin suscripciones, funciones innecesarias ni una conexión a Internet solo para reproducir tu propia música.

Después llegó la parte menos glamurosa: las pruebas cerradas de Google Play.

Antes de que una aplicación Android pueda llegar a producción, Google Play exige una prueba cerrada con al menos 12 testers inscritos durante el periodo requerido. Sobre el papel parece sencillo. En la práctica, encontrar a 12 personas es solo el principio.

Para Kleos Music encontramos a la mayoría de nuestros testers mediante comunidades de tester-for-tester, o T4T, donde los desarrolladores prueban las aplicaciones de otros desarrolladores, y a través de r/AndroidClosedTesting en Reddit. Era una forma práctica de conseguir que las primeras personas utilizaran la aplicación fuera de nuestros propios dispositivos.

Pero hay una diferencia importante entre tener 12 testers y probar realmente una aplicación.

Un tester puede inscribirse y no volver a abrir la aplicación. Otro puede utilizarla una vez y desaparecer. Alguien puede encontrar un error y nunca reportarlo. Por eso, depender exactamente del mínimo de testers es arriesgado. La gente deja de participar, se olvida de la prueba o simplemente deja de estar activa. Tener cierto margen por encima del mínimo hace que el proceso sea mucho más sólido.

Y, sobre todo, las pruebas reales cambian la forma en la que ves tu propio producto.

Cuando construyes una aplicación tú mismo, ya sabes cómo funciona. Sabes dónde están los ajustes. Sabes qué botón abre cada pantalla. Sabes que existe un determinado gesto porque tú mismo lo has programado.

Un tester no tiene ese conocimiento.

Esa diferencia sacó a la luz cosas que probablemente habríamos pasado por alto.

Diferentes versiones de Android se comportaban de forma distinta. Las pantallas tenían proporciones diferentes. Los widgets necesitaban ajustes. Las notificaciones multimedia presentaban problemas de compatibilidad. La coincidencia de metadatos se comportaba de forma diferente con bibliotecas musicales poco habituales. Incluso algo tan sencillo como explicar cómo escanear manualmente una carpeta de música resultó ser menos evidente de lo que pensábamos.

Cada descubrimiento pasó a formar parte del ciclo de desarrollo.

Usar la aplicación. Encontrar algo. Reportarlo. Arreglarlo. Crear una nueva versión. Volver a probar.

Durante la prueba cerrada, Kleos Music pasó por build tras build. Algunos cambios fueron pequeños. Otros afectaron a partes completas de la experiencia. Lo importante no era el número de builds. Era que cada build representaba algo que habíamos aprendido del uso real.

Esto también nos hizo pensar de otra manera sobre otro proyecto de Kleos, Kleos Breathe.

Breathe nos enseñó el otro lado de las pruebas cerradas. El problema no era que hubiéramos descubierto cientos de bugs. Era casi lo contrario: no había suficiente interacción. Había poco feedback, pocos problemas reportados y, por tanto, muy pocas señales de que el producto estuviera conectando con los testers.

Aquella experiencia cambió nuestra forma de entender las pruebas.

Una prueba cerrada no es simplemente una barrera que tienes que superar antes de llegar a producción. También puede funcionar como un filtro para el propio producto.

Si la gente utiliza repetidamente una aplicación muy poco, no vuelve a ella y apenas tiene algo que comentar, la respuesta no siempre es buscar más testers. A veces el propio producto necesita replantearse.

Para nosotros esa diferencia fue importante. Kleos Music generaba preguntas porque la gente realmente la estaba utilizando. Breathe generaba mucha menos información porque había mucha menos interacción. Las dos experiencias fueron útiles, pero de formas completamente diferentes.

Google también pide a los desarrolladores que expliquen qué ocurrió durante la prueba cerrada cuando solicitan acceso a producción. Eso incluye cómo se consiguieron los testers, cómo utilizaron la aplicación, qué feedback proporcionaron, qué cambios se realizaron a partir de ese feedback y por qué consideramos que la aplicación está preparada para producción.

Para nosotros, esas preguntas no fueron simplemente otro formulario. Fueron casi un resumen del propio proceso de desarrollo.

Podíamos hablar de conversaciones reales con testers, problemas reales descubiertos en dispositivos reales y correcciones reales que habíamos publicado como respuesta.

Probablemente eso fue lo más valioso que nos llevamos de las pruebas cerradas de Google Play.

Nos obligaron a cuestionar suposiciones que ni siquiera sabíamos que teníamos.

Pensábamos que determinadas pantallas escalarían correctamente. No siempre fue así.

Pensábamos que ciertas interacciones serían inmediatamente evidentes. No siempre lo fueron.

Pensábamos que nuestro sistema de metadatos se comportaría igual con cualquier biblioteca musical. Las bibliotecas reales demostraron ser más complejas.

Y pensábamos que, si algo tenía sentido para nosotros, tendría sentido para todo el mundo.

No es así.

Por eso las pruebas de aplicaciones Android son mucho más que comprobar si una aplicación se bloquea. Una buena prueba cerrada revela la distancia entre lo que el desarrollador quería construir y lo que el usuario realmente experimenta.

Para kleosvic, esa distancia fue precisamente donde ocurrió gran parte del trabajo útil.

El objetivo nunca fue simplemente alcanzar el requisito de 12 testers y pulsar el botón de producción. El objetivo era utilizar el periodo anterior al lanzamiento para hacer que el producto fuera mejor.

Empezamos el proceso pensando que estábamos probando una aplicación.

Terminamos probando nuestras propias suposiciones sobre la aplicación.

Y eso resultó ser mucho más útil.