A la hora de probar y verificar una aplicación que hemos desarrollado en Android tenemos varias fases intermedias. No son obligatorias, ayudan a mejorar la calidad de la aplicación. Podemos distinguir dos tipos de errores. Por una parte tenemos los errores de funcionamiento por otra parte los errores de diseño. Un error de funcionamiento sería que el usuario pierda los datos por un bloqueo de la aplicación. Por su parte, un error de diseño podría ser que el interfaz no se adaptara a la pantalla.

Los dos tipos de errores se pueden detectar en la fase de  testeo. En algunas ocasiones quedan enmascarados por el propio programador. Supongamos que un error aparece en unas condiciones concretas que no probamos. Al trabajar siempre de la misma forma no activamos el error. Cuando otro usuario utiliza la aplicación siguiendo otro orden lo encuentra.

¿De qué forma podemos detectar estos problemas antes de que publiquemos la aplicación? Recordad que los usuarios son nuestros clientes aunque la aplicación sea gratuita. Si al usarla encuentran errores es posible que escriban comentarios negativos. Ésto se traducirá al final en menos descargas de usuarios nuevos. Cuando la aplicación es de pago los resultados pueden ser peores. La solución de este problema es relativamente sencilla. Consiste en verificar de forma adecuada la aplicación antes de su lanzamiento.

Errores de funcionalidad

Los errores de funcionamiento se pueden detectar de forma manual o de forma automatizada si usamos pruebas unitarias. Una prueba unitaria se puede considerar como una función de verificación que llama a la función real de nuestra aplicación. Le introduce los datos y comprueba el resultado de la operación. Los datos que introduce los decide el programador y pueden ser datos válidos o erróneos.  La función que esté bajo prueba debe responder de forma adecuada aunque la introducción sera errónea. Supongamos que la función original espera un texto de 100 caracteres y le pasamos una cadena que tiene 1000 caracteres. De forma transparente al usuario debemos procesar la información y si es necesario informar al usuario de que el texto tiene que ser más pequeño.

Las pruebas unitarias tienen otra ventaja respecto a las pruebas manuales. Al añadir una función nueva es fácil que afecte a otras partes de la aplicación si comparten datos o se ha cambiado la estructura de los datos. Antes de probar la aplicación en un terminal real pasamos toda la batería de pruebas. Si se produce un error tendremos localizada la función en la que se encuentra y el tipo de datos que se le ha introducido. Un ejemplo de esto puede ser una función que trata con una base de datos. Si la función 1 espera los datos de una forma (de una sentencia SQL) y la función 2 los necesita de otra (con la misma sentencia SQL) podemos romper la función 1 con la función 2.

Errores de diseño

Los errores de diseño muchas veces son evidentes como el ejemplo de la aplicación que se sale de la pantalla pero en ocasiones son más sutiles. El diseño de la aplicación puede ser correcto para una pantalla de 4,5 pulgadas pero ser incomodo si usamos una pantalla más pequeña. Para estos casos es posible aplicar un diseño personalizado para pantallas pequeñas para que la experiencia del usuario sea adecuada. Estos detalles no los podemos ver si hacemos las pruebas siempre en el mismo tipo de dispositivos y de la misma forma. Necesitaremos por tanto que otros usuarios prueben nuestra aplicación y nos ofrezcan realimentación. Según el alcance de la prueba podemos distinguir dos casos:

• La prueba se realiza en un ámbito local con pocos usuarios.
• La prueba se realiza en un ámbito global con muchos usuarios.

En el primer caso los usuarios que prueban la aplicación pueden ser conocidos, amigos e incluso familiares. La ventaja de esta forma de trabajar es que controlamos a los usuarios que hacen la prueba pero tiene como inconveniente que la mayoría de los usuarios no serán “clientes” de la aplicación. Con esto me refiero a que si realizamos un contador de viajes para el transporte público los usuarios que prueban la aplicación deberían ser aquellos que la usarían a diario. El resto de usuarios puede probar la aplicación pero no nos dará tanta información útil. En el extremo opuesto está el segundo caso: tenemos usuarios interesados en la aplicación pero no controlamos quien la instala. La elección entre ambos casos no es excluyente sino que podemos realizar una primera etapa con el primer caso y después pasar al segundo.

Acceder a una versión beta (como usuario)

Para realizar la prueba usaremos Google Play y una comunidad de Google+. El funcionamiento es sencillo. Al unirnos a la comunidad de la aplicación que realiza la prueba activaremos una opción “especial” en Google Play. A partir de ese momento cuando instalemos la versión oficial de la aplicación estaremos instalando realmente la versión beta. El proceso es reversible y podemos volver a la versión estable en cualquier momento. Antes de pasar a una versión beta hay que comentar que si bien la versión es suficientemente estable, pueden aparecer errores de diferentes tipos.>Si usamos el terminal con >Android> y una aplicación crítica para el trabajo no hay que pasar a una versión beta de esa aplicación.

Explicaré los pasos para entrar en el programa de beta de la aplicación Todoist. Hay muchas aplicaciones que están siguiendo este tipo de desarrollo, sólo tenéis que investigar un poco por Google Play. Iniciamos la sesión en la cuenta de Gmail y entramos en la comunidad de Todoist.

Comunidad de Todoist

Los pasos para activar el programa de verificación están en la columna derecha de cada página. Tenemos que pulsar en el enlace que nos dan y nos saldrá una pantalla similar a la siguiente:

Programa de beta

Es suficiente con pulsar en el botón y a continuación pulsar en el enlace inferior: Descargar Todoist: Lista de tareas de Play Store. Con esta función podemos como usuarios acceder a versiones en desarrollo y sugerir funciones a las aplicaciones que más usamos en el terminal con Android.

Conclusiones

El desarrollo de una aplicación exige varias habilidades en todas las fases. Durante la creación tenemos que aplicar técnicas de diseño (respetar las guías de estilo de Android), programación (lógica de la aplicación) o marketing (para publicar la aplicación en Google Play).  En cada una de las fases podemos usar diferentes herramientas que facilitan la creación de la aplicación. En el diseño podemos diseñar el interfaz de usuario con Fluid UI en el PC o con la aplicación POP usando bolígrafo y papel en un terminal con Android. Para la programación tenemos Eclipse y la documentación de Android mientras que para el marketing podemos realizar pruebas de la aplicación en grupos reducidos limitados o en grupos amplios perdiendo parte del control de la prueba.