¿Su sitio web o aplicación móvil está plagado de fallos y no sabe qué hacer? En este artículo, explicamos las diferentes causas de los fallos y qué técnicas puedes utilizar para prevenirlos al máximo.
Érase una vez un bicho, y luego otro, y sigue y sigue, y esto es sólo el principio, vale, vale. No pasa una semana sin que descubras un nuevo fallo en tu sitio web o aplicación móvil. Y sinceramente, no estás lejos de arrancarte los pelos. No sabes qué hacer con ellos. Admitámoslo: no existe un sitio web o una aplicación móvil sin errores. Es un mito. O al menos, una rareza. Y aunque es utópico erradicar totalmente los fallos en las plataformas web y móviles, actualmente existen nuevas técnicas para minimizar su número. Pero empecemos por entender de dónde vienen en primer lugar.
¿Qué causa los insectos?
Un botón que no funciona, una mala visualización, un error 404, un problema de conexión: las anomalías en los sitios web o las aplicaciones móviles pueden deberse a multitud de motivos. Empezando por el factor humano. Porque mientras las plataformas web o móviles sean desarrolladas por humanos, pueden producirse errores. Pero aquí hay algunas causas comunes que pueden llevar a los insectos:
>> Regresiones :
Las regresiones se producen siempre que un cambio de código afecta al código existente. Por ejemplo, cuando se implementa una nueva función, si ésta altera el comportamiento de las funciones existentes anteriormente, se ha producido una regresión, ya que se ha introducido un error.
Pero, ¿cuáles son las razones de la regresión? Puede deberse a que el código está mal diseñado, a que hay una mala gestión de los errores, a un sistema de control de versiones deficiente, a una mala corrección antes de la fusión, a unas prácticas de desarrollo deficientes (o a la ausencia de prácticas), o a que los equipos trabajan de forma demasiado independiente, de modo que los módulos en los que están trabajando pueden repercutir unos en otros.
>> La falta de pruebas:
¿Probar significa dudar? Algunos dirían que sí, pero serían pretenciosos. Porque si el software o la aplicación no se ha probado a fondo, desde el principio de su ciclo de desarrollo hasta que se pone en producción (e incluso después, para el caso), entonces hay una probabilidad muy, muy, muy (nunca hay demasiado de un muy) alta de que se encuentren errores en la producción. ¿Y realmente necesitamos que se nos recuerde de nuevo el impacto que puede tener un error en un usuario final?
Cuidado: probar es bueno (incluso muy, muy, muy bueno), pero todavía hay que probar bien. Y para ello hay que elegir las pruebas adecuadas y hacerlas en el lugar correcto. Este es uno de los principios fundamentales de las pruebas: las pruebas muestran la presencia de defectos, pero no demuestran su ausencia. Por eso es importante hacer las pruebas bien y en el lugar adecuado, para identificar los fallos más críticos de forma eficiente. Las pruebas son la medida esencial de la calidad de las aplicaciones.
>> Una falta de comunicación:
¿Es la falta de comunicación la causa de todos los males del mundo? Puede ser, y una cosa es cierta: provoca muchos fallos. Porque, como todos sabemos, la falta de comunicación entre los equipos da lugar a malentendidos, a suposiciones, pero también a incomprensiones. Y en el contexto del desarrollo web o móvil, todo el tema de la comunicación comienza en la fase de especificación.
Las especificaciones se utilizan para describir la visión de las personas que las crean. Por ejemplo, el negocio tiene una necesidad y el Product Owner escribirá las especificaciones. A continuación, los desarrolladores elaborarán las especificaciones, y luego los probadores pondrán a prueba los desarrollos de las especificaciones. Y si hay lagunas en la comunicación entre estas diferentes personas, si todo el mundo no se comunica eficazmente para desarrollar el producto y si cada capa está aislada, se crea un efecto túnel que puede conducir a defectos críticos y el usuario final es el que recoge los pedazos.
Pero, ¿cómo se pueden prevenir estos fallos?
Ya hemos mencionado en un artículo anterior algunos consejos para evitar y limitar los errores, centrándonos en la calidad, pero también hay técnicas de desarrollo que pueden prevenirlos.
>> TDD (Desarrollo Dirigido por Pruebas) :
El desarrollo dirigido por pruebas es un método de desarrollo que consiste en escribir pruebas antes de escribir el código. ¿Pero qué más? Básicamente, primero se escribe una prueba, se ejecuta y luego se valida que la prueba ha fallado, ya que la funcionalidad aún no se ha implementado. A continuación, se desarrolla la funcionalidad y se repite la prueba hasta que se supera, etc.
¿Por qué este método funciona contra los bichos? Porque si las pruebas se crean antes de que se desarrolle la función o el producto, la probabilidad de que la función o el producto lleguen a los usuarios finales sin haber sido probados se reduce considerablemente. Además, las pruebas periódicas permiten detectar antes los fallos y corregirlos antes de que pasen a producción.
Ten cuidado, sin embargo, TDD sigue estando muy centrado en las pruebas unitarias y requiere un trabajo previo para definir las pruebas, lo que a veces es complicado de implementar en un proyecto urgente.
>> BDD (Desarrollo Orientado al Comportamiento) :
El Desarrollo Orientado al Comportamiento, que difiere del TDD, fomenta la comunicación y la colaboración entre todas las partes implicadas en el proyecto (desarrolladores, ingenieros de calidad, gente de negocios, probadores, etc.). Esto garantiza que todo el equipo tenga un entendimiento común de cómo debe comportarse la aplicación. Esto se consigue escribiendo pruebas en un lenguaje que todos puedan entender, antes de que comience el desarrollo de la función o el producto. Gracias a este método BDD, es posible identificar los errores en una fase temprana del proceso de diseño y así prevenirlos.
>> Integración continua / Pruebas continuas :
Empecemos por el principio. El enfoque CI, también conocido como integración continua, es un método para integrar el nuevo código escrito por los desarrolladores en el código fuente de una aplicación lo antes posible y con la mayor frecuencia posible (al menos una vez al día) a lo largo del ciclo de desarrollo. Las pruebas automatizadas se realizan cada vez que se modifica el código fuente (de ahí las pruebas continuas), para comprobar que no se ha producido ninguna regresión y que las nuevas funcionalidades se implementan correctamente.
Esto garantiza una supervisión continua a lo largo del ciclo de vida de la aplicación y, en particular, asegura que todas las regresiones se detecten tan pronto como se introduzcan. Esto ahorra mucho tiempo y esfuerzo que, de otro modo, se emplearía en encontrar los cambios que causaron la regresión, por ejemplo.
Sin embargo, esto requiere una inversión muy importante en la automatización de todo tipo de pruebas (unitarias, de integración, de sistema, de extremo a extremo, etc.).
>> Tenga en cuenta que estas técnicas de desarrollo no necesariamente funcionan para todos. Depende de la estructura, la dinámica de su equipo, el contexto del proyecto, su estrategia de pruebas, etc. Con todas estas técnicas de prevención, sin embargo, no eres inmune a dejar pasar un fallo (el fallo cero no existe), pero no deberías dejar pasar los más críticos, que son los que más impacto tendrán.
Conclusión
En resumen, para gestionar mejor los bugs es necesario, en primer lugar, ser capaz de detectarlos, y esto requiere simplemente la aplicación de enfoques basados en pruebas. Sin embargo, como decíamos más arriba, no basta con probar, hay que probar bien y esto requiere una documentación viva a través de las pruebas y, en particular, de las pruebas automatizadas. Pero eso será objeto de un futuro artículo ;)
