¿Productos de calidad y sin bugs? Sigue estas 6 claves.

Muchos creen que basar la calidad de software en hacer pruebas al código entregado por cada desarrollador es correcto, pero desde Paradigma creemos que es una práctica errónea. La calidad se trabaja desde las fases más tempranas y no se debe obviar durante ninguna de las fases, hasta el último día del proyecto.

Seguramente, si preguntamos en muchas empresas que hablan de la calidad de sus productos, no sepan decirnos qué hacen realmente para trabajar dicha calidad.

Desde Paradigma no solo se nos anima a trabajar con la últimas tecnologías, sino que también se impulsa el trabajar buscando mayor calidad en todo momento.

Es por ello que desde el equipo de QA hemos definido 6 puntos claves que nos ayudan a tener casos de éxito en nuestros proyectos.

Definición de requisitos

Este el primer paso en cualquier desarrollo. Es el momento en que se define qué es lo que queremos tener y por qué.

Desde Paradigma se promueve el llamado “Sprint 0”. Es una fase inicial al proyecto que nos permite identificar los objetivos y reducir la incertidumbre respecto al alcance.

Gracias a él producimos todo lo necesario para poder comenzar a trabajar con un enfoque ágil.

Independientemente de tener “Sprint 0” o no, trabajamos en la definición de requisitos junto al Product Owner durante todos los sprints. Esto nos ayuda a:

• Detectar y definir casuísticas más extrañas.
• Dar un punto de vista más técnico a los requisitos.
• Detectar y solventar dudas e impedimentos antes de la fase de desarrollo.

Uno de los problemas que he detectado durante mi experiencia, es que frecuentemente se suele tener definiciones generalizadas en los requisitos, que van tomando forma durante el sprint.

Los requisitos deben ser claros y sin definiciones abiertas que den lugar a dudas. No hacerlo así puede llevarnos a equívocos durante el desarrollo y acabar provocando fallos tanto a nivel de código como a nivel funcional.

Existen técnicas que nos ayudan con esto, entre las que destaca BDD (Behavior Driven Development), que se basa en definir las funcionalidades en un lenguaje común, tanto para negocio como para el equipo de desarrollo.

Frecuentemente, esto se consigue a base de ejemplos en cada funcionalidad y sus diferentes casuísticas, lo cual facilita que sea entendido por personas de cualquier ámbito.

Recordemos que en agile, todos los equipos deben trabajar con un DOR (Definition Of Ready), el conjunto de los requisitos mínimos que tiene que cumplir una tarea del backlog para poder ser añadida en un Sprint. Uno de estos requisitos podría ser: “los criterios de aceptación están definidos claramente y están validados por el P.O.”

Automatización de pruebas

Con el tamaño de las aplicaciones actuales, es prácticamente imposible probar de forma manual toda una aplicación con cada cambio de código. Es por ello que en las pruebas manuales solemos centrarnos en probar los nuevos desarrollos.

Esto suele provocar errores, ya que un simple cambio puede afectar a muchas partes de nuestro código que no tienen porqué tener una relación directa con los cambios realizados.

Las pruebas manuales ayudan y a veces son necesarias, pero es mucho más importante tener una buena cobertura de pruebas automatizadas. Por ejemplo, en Paradigma trabajamos con un Quality Gate de Sonar que no nos permite subir código con un porcentaje menor al 65% de cobertura de código, pero desde la misma herramienta recomendamos trabajar con un porcentaje mayor al 80%.

Las pruebas automatizadas nos garantizan que tanto el nuevo desarrollo, que ha sido cubierto por nuevas pruebas, como los anteriores que ya tenían las suyas, funcionen perfectamente. Todo ello con un tiempo de ejecución muchísimo menor al de realizarlas de forma manual.

Independientemente del número de tests automatizados, hay que hacer hincapié en que estos deben estar bien desarrollados y tener sentido. Antes de ponernos a desarrollarlos, debemos de pensar qué flujos queremos y debemos cubrir.

Muchas veces trabajamos que aumentar la cobertura de los tests, pero no siempre una mayor cobertura te asegura un producto menos propenso a bugs.

Para ayudarnos con esto tenemos técnicas como TDD (Test-Driven Development) o en su traducción, desarrollo dirigido por tests. Es una práctica que consiste en escribir primero las pruebas y después escribir el código fuente haga que estan pasen satisfactoriamente.

Desarrollo de flujos automáticos

En Internet hay muchísima información referente a flujos de Integración Continua, pero ¿qué nos aportan realmente? ¿Cómo nos ayudan a evitar bugs?

Durante el desarrollo de nuestros productos debemos tener automatizados el mayor número de fases posibles, como:

• Compilación
• Ejecución de tests
• Análisis de código
• Entrega de código
• ...

El número de fases dependerá de las necesidades y características técnicas del proyecto. Tener automatizado un flujo completo que vaya desde la creación o aprobación de una merge request hasta el despliegue en el entorno correspondiente, nos ofrece estas dos ventajas:

Reducción de tiempos

Al tenerlo automatizado, todo fluye mucho más rápido. No tenemos que estar esperando ningún paso manual de una persona que pueda estar ocupada en el momento que más la necesitemos.

Esto es importante, porque tiempo que ahorremos con esto, es tiempo que podemos dedicar a otras tareas que ayuden a conseguir el objetivo.

Evitar entornos y configuraciones inestables

Si cada miembro del equipo tuviera que realizar estas tareas de forma manual, estas acabarían siendo realizadas de forma distinta, sobre diferentes entornos y posiblemente con diferentes configuraciones.

Los pasos manuales puede provocar que tengamos falsos positivos en alguna de las fases y que pensemos que tenemos todo controlado cuando no lo está.

Lo ideal es disponer de flujos automatizados que levanten instancias docker en cada ejecución. Estas instancias siempre se levantan con las mismas configuraciones, variables, versiones... lo cual nos da una gran estabilidad y evita posibles bugs no detectados por “fallos” en entornos locales.

Calidad del código

Se suele decir que existen dos tipos de código, el que funciona y el que no, pero no es cierto. Como mínimo, se podría decir que existe el bueno y el malo. El código no solo tiene que funcionar correctamente. Además de ello, tiene que tener calidad que evite futuros bugs.

Para ello, hay que trabajar en puntos como: código duplicado, código muerto, estándares de codificación, complejidad ciclomática, comentarios...

Desde el equipo de QA nos encargamos de la administración de Sonarqube. Esta es la herramienta principal usada por los equipos de desarrollo para analizar el código. Con ella, revisamos los puntos nombrados anteriormente, entre muchos otros.

En Sonarqube tenemos quality profiles para distintos lenguajes que han sido definidos y revisados por miembros de diferentes áreas, como QA o Arquitectura. Con esto nos aseguramos de que las reglas asignadas a cada lenguaje han sido analizadas y validadas.

Si queréis profundizar en este tema, también podéis ver este post publicado recientemente, que habla de forma más detallada sobre la calidad del código y Sonarqube.

En Paradigma estamos muy concienciados y continuamente se ofrecen talleres, meetups y seminarios relacionados con el tema.

Respetar los tiempos

Independientemente de su importancia por separado, los puntos anteriores tienen algo en común. Todos requieren de una dedicación que debe ser respetada desde el primer hasta el último minuto.

Bajo mi punto de vista, los recortes de tiempos son el principal enemigo de un producto de calidad, ya que generan muchísimos problemas y bugs durante las diferentes fases.

La relación calidad/tiempo es algo que se puede extrapolar a cualquier ámbito de nuestras vidas. Si haces algo rápido, acabas obteniendo un peor resultado. Incluso acabas perdiendo más tiempo arreglando errores producidos por las prisas. Todo esto se puede evitar si le dedicas el tiempo necesario desde el primer momento.

La calidad es cosa de todos

Si has llegado a leer hasta aquí, seguro que se te ha venido a la mente el rol QA, pero esto es un error muy común. Es cierto que el QA es la cabeza visible si hablamos de la calidad de un proyecto, pero la realidad es otra. La calidad es responsabilidad de todos y cada uno de los miembros del equipo.

En algunas empresas se trabaja con un equipo de calidad externo al de desarrollo. Este equipo entra en una fase posterior, lo cual va en contra de lo nombrado anteriormente.

Lo más aconsejable es que todo el equipo se sienta responsable de la calidad durante todo el proceso de desarrollo y se centre en tratar de prevenir y evitar los errores, en lugar de buscarlos.

Ya hablamos en el blog de las consecuencias de que los equipos no se sientan involucrados en la calidad durante todo el proceso y cómo grandes corporaciones como la NASA, Microsoft o Amazon han sufrido consecuencias graves por errores que se podían haber evitado.

Evitarlos y localizarlos en fases pre productivas es algo clave y necesario, ya que puede tener consecuencias nefastas. Las consecuencias pueden ir desde la pérdida de millones de euros hasta la pérdida de vidas humanas.

Quizás, hablar de un producto con 0 bugs es algo que puede sonar exagerado. Independientemente de conseguir la perfección o no, estas 6 claves que hemos detallado nos ayudarán y mucho a acercarnos a nuestro objetivo.

“La calidad nunca es un accidente, siempre es el resultado de un esfuerzo inteligente”

John Ruskin

Escritor