Desarrollo de apps: cómo realizar las pruebas y el testeo en móvil

En los trabajos de alto riesgo siempre se dice que toda precaución es poca, ya que un accidente en ese entorno puede llegar a costarnos la vida. En el mundo del desarrollo suceden cosas parecidas y subir a producción una app o un código sin haber realizado las pruebas necesarias puede llegar a crear un estado de pánico importante en función de nuestro cliente final. Las pruebas de depuración, tests, y otro tipo de comprobaciones relacionadas con el control de calidad del software deben ser ejecutadas en todo momento, ya sea con integración continua, durante el desarrollo o en las subidas a predesarrollo. ¿Qué significan estos conceptos y qué tipo de pruebas hay? A continuación os explico un poco más sobre el control de calidad del código.

Control de calidad de código en apps y todo tipo de software

En desarrollo hay varios tipos de pruebas: integración continua, depuración de errores o las conocidas “User Acceptance Test”. Todas estas pruebas se pueden englobar como pruebas de regresión, aunque no todas entran dentro de este grupo. Hoy me gustaría hablar de la depuración y las UATs, ya que son las menos complejas de llevar a cabo y no necesitan una infraestructura dedicada, como puede ser Jenkins, un software dedicado a realizar un seguido de test, uno detrás de otro, o Pipelines, y el cual necesita un servidor dedicado, un control de versiones con Git y una automatización de procesos. Esto es algo muy usado en empresas medianas y grandes, pero no es lo mejor para empezar en el mantenimiento de código. Empecemos por la depuración y sigamos con las UAT.

Depuración. Tal vez lo conozcáis como Debugar, debido a que el botón que presionamos en nuestro editor de código, IDE o navegador web pone “debug”. Es muy importante que dominemos esta posibilidad, ya que gracias a la depuración podemos detener el código en un punto de ejecución, lo que nos permite observar el estado de las variables u otros objetos de nuestro código. Digamos que queremos ver cómo se llena un array en cada vuelta de un bucle, ya que nos da un error en algún punto de ese estado. Con la depuración podemos poner un punto de ejecución, o breakpoint, dentro de nuestro bucle “for” y observar en la consola como van cambiando los miembros de dicho array. Esta opción existe en todos los IDE modernos, por lo que os recomiendo investigar qué herramienta queréis usar en vuestro desarrollo, ya sea JAVA, web o aplicaciones móviles. Por ejemplo, si queréis hacer apps para Android de forma nativa, es recomendable usar Android Studio, o si por lo contrario se trata de iOS, usar Xcode. Si sois más aventurados y expertos, pero, un editor de código como Atom o Visual Studio Code integran módulos para poder depurar, pero es necesario un conocimiento más avanzado de la materia ya que no es sencillo.

User Acceptance Tests, o UATs. Este tipo de pruebas se deben realizar una vez la fase de depuración ha finalizado y nos hemos asegurado que no hay errores de sintaxis en nuestro código y no produce ningún tipo de error. Una vez hemos comprobado esto, y hemos subido nuestro código a nuestro control de versiones, preferiblemente GIT, ya sea con GitHub o Bitbucked, procedemos a hacer las UAT. ¿En qué consiste? Muy sencillo. Debemos realizar un listado de tareas óptimas y obligatorias que nuestro software debe llevar a cabo sin problemas. Estas tareas pueden ser desde abrir la aplicación hasta presionar un botón para compartir en redes sociales. Aquí es necesario hacer una lista honesta de funcionalidades, desde la más mínima hasta la más necesaria. Siempre que se detecte que una de estas tareas no produce el resultado esperado, se marca como un error. Estas comprobaciones es ideal que lo realice alguien ajeno al equipo de programación, como un equipo de testers. Pero si no disponemos de esta plantilla, nuestros compañeros que no hayan tocado el código son totalmente válidos. ¿Por qué? Os sorprendería ver cuantas UAT han realizado los propios programadores y se han dejado casos por el camino porqué, de forma inconsciente, conocen el código y creen que no es necesario pasar por ahí. Como anécdota amarga propia: una vez tuvimos que realizar unas UAT para un nuevo aplicativo bancario y, después de hacer una subida a preproducción pensando que todo estaba bien, recibimos una alerta al cabo de unas horas de que algo tan simple como que un modal de “cargando” se mostrase, efectivamente no aparecía nada. ¿El encargado de detectar este resultado? Un servidor vuestro que escribe en este blog.

En definitiva, como podéis leer no es necesaria una gran infraestructura moderna si queremos hacer un mínimo de mantenimiento de calidad en nuestro código, ejecutando un seguido de tareas nosotros mismos para determinar y detectar la calidad del código y no proceder si hay errores. Hay mucha información realmente de todo esto y creedme que es relativamente sencillo de implementar esta costumbre en los equipos de desarrollo sin necesidad de pasar a procedimientos más grandes como una Integración Continua con Jenkins. Es más, en el último mes mi tarea en mi trabajo ha sido ser miembro de un equipo de migración del control de versiones y empezar a implementar Jenkins. Mi tarea no ha acabado aún, pero voy por buen camino y sin embargo no tenía experiencia previa.

Curso relacionado: Curso Superior de Desarrollo de Aplicaciones para Móviles