¿El aseguramiento de la calidad es una pérdida de tiempo?
¿El aseguramiento de la calidad es una pérdida de tiempo?
Es común creer que empezar a probar antes garantiza la calidad y ocurre lo opuesto ¿Por qué? Vamos a encontrar la respuesta a esta cuestión
Un directivo de una institución de gran tamaño, nos habló acerca de su inversión en Testing y lo orgulloso que estaba de la estrategia que había planteado. El proceso de testing del software que producían tenía varias fases, cada una con diferentes recursos, infraestructura y pasos a seguir. Según él, si una fase encontraba más defectos que la anterior, significaba que estaba habiendo un gran trabajo de calidad, porque dejaría el software libre de fallos y defectos.
Nos costó mucho tiempo convencerle de que estaba ocurriendo justo lo opuesto: mientras más defectos encuentras en testing, más defectos quedan por encontrar. Muchos de esos defectos se manifestarían en producción, algo que efectivamente estaba ocurriendo, con frecuencia, en esa empresa.
¿Cómo es que ocurre esto? ¿Cuáles son las convicciones que nos conducen a situaciones así? Vamos a encontrar la respuesta a estas cuestiones.
Creencia falsa: mientras más pronto lleguemos a pruebas, tendremos más tiempo para estabilizar el software
Quizás has vivido una situación así: los tomadores de decisiones establecen el objetivo de "llegar a testing cuanto antes" y suprimen muchas actividades, bajo el argumento de "no tenemos tiempo para eso". Aceleran la producción del código y lo entregan a pruebas, fase en la que dedican un tiempo igual o mayor al que les tomó construir el código en primer lugar.
Incluso, algunas organizaciones ofrecen a sus clientes una "fase de estabilización", que describen como "el período de tiempo en el que arreglamos todos los problemas que puedan surgir y reparamos los defectos", lo cual es terrible, ¿por qué tenemos que cobrarle al cliente por nuestra mala calidad?
Creencia falsa: testing es suficiente para asegurar la calidad
Testing, como su nombre lo indica, pone a prueba nuestro producto. La misión de nuestro producto es superar esas pruebas exitosamente, porque así demuestra su solidez. ¿Acaso tú comprarías un coche, que sabes que falló las pruebas muchas veces, o entrarías a un edificio que también tuvo muchos problemas en testing? Te aseguro que no, pero con el software pensamos distinto.
Testing tiene como objetivo encontrar defectos, pero se enfoca en cierto tipo de ellos, no en todos. Un proceso de pruebas, muy riguroso, encontrará la mitad de los defectos presentes en el producto, porque hay cierto tipo de problemas que no se pueden rastrear (un tipo de dato declarado incorrectamente o un parámetro en el orden incorrecto, por citar algunos ejemplos).
Las actividades de testing son importantes, pero son solo un conjunto de todas las formas posibles de asegurar la calidad, no la única. Tu estrategia debe incluirlas, junto con otro grupo de prácticas que te asegurarán una mejor calidad.
Otras causas: ignorar que hay otras formas
Conozco muchos desarrolladores (algunos de ellos en nivel "senior") que solo saben usar la técnica de code-and-fix: escribir código y ejecutarlo para probarlo poco a poco. Esto funciona en programas pequeños, pero es ineficiente en sistemas más grandes. La razón de esto es que no conocen otra forma de asegurar la calidad: creen que solo pueden asegurar su trabajo si ejecutan el sistema, lo que se conoce como pruebas de caja negra. Esto se resuelve enseñándoles otras técnicas, de las que te hablaré más adelante.
Los líderes que usan el argumento "no tenemos tiempo para eso" creen que toda actividad que sea diferente a crear el código los retrasará, cuando son esas actividades las que garantizan las entregas más rápidas. Nada es más rápido que entregar bien a la primera. Solucionar esto es más difícil, pero no imposible.
Estrategia de aseguramiento de la calidad
Te he hablado anteriormente de lo importante que es establecer una cultura de la calidad en todo el proceso. El objetivo debe ser el de cero defectos en producción, por lo tanto, hay que encontrar y reparar todos los defectos antes de hacer el despliegue. Incluso, hay que arreglar el 80% de ellos antes de testing.
Por lo tanto, te sugiero que incluyas algunas de estas técnicas a lo largo del desarrollo para alcanzar este objetivo:
Revisiones personales: esta es una actividad obligatoria, porque es el compromiso individual hacia la calidad. Consiste en crear checklist y revisar minuciosa y personalmente el trabajo recién terminado, con el fin de remover los defectos más comunes que he inyectado en el pasado. Es útil para detectar problemas tales como: pares de apertura y cierre, typos en el nombrado de variables e instrucciones, tipos de datos erróneos, pase de parámetros, condiciones y ciclos y lógica básica de funciones.
Revisiones entre pares: actividades de verificación entre una o más personas. Su propósito es encontrar defectos estructurales y omisiones graves, que causen problemas graves. Son procesos estructurados y costosos en esfuerzo, por lo cual se recomienda hacerlos solo para ciertos componentes o elementos del producto (como la revisión de la arquitectura o la validación de un componente crítico). No se debe hacer con todos los productos y todo el código, porque su costo es alto y no es útil para todos los tipos de defectos. Un Pull Request es un ejemplo de este tipo de técnica.
Peer Programming / Mob programming: actividades en las que dos o más personas construyen el software a la vez. Su ventaja es que todos los pares de ojos proponen la implementación, detectan omisiones en tiempo real y sugieren las mejores soluciones. A la vez, se cuidan otros aspectos, como el estándar de codificación, la sintaxis y los acuerdos de la arquitectura. También son útiles para emparejar el nivel de varios ingenieros, al estar cerca de personas con más experiencia.
Análisis estático del código: es una actividad automática. Uno o varios programas (como SonarQube) revisan continuamente el código fuente para detectar algunos defectos, tales como omisión de estándares, complejidad ciclomática alta, variables sin uso o errores en el nombre, parámetros incorrectos, code coverage, entre otros. Se recomienda que uses esto para automatizar la localización de algunos defectos menores y usar las otras técnicas para la búsqueda de problemas más serios.
Diseño detallado de la solución (incluye TDD): el diseño de la solución, que consiste en pensar en una solución y sus posibles escenarios para validar la mejor alternativa, es una práctica que asegura la calidad y previene defectos. Esto incluye el uso de herramientas para plantear algoritmos (diagramas de flujo, etc.), interacción entre componentes e interfaces o esquemas revisados en grupo para validar la solución e implementarla. También, es útil para asentar y comunicar acuerdos. Genera alguna documentación, como las Pruebas Unitarias creadas con TDD (que es, a la vez, un documento de diseño)
Conclusiones
El aseguramiento de la calidad no es una pérdida de tiempo, no importa lo que diga tu líder cuando le propones hacerlo y espeta "no hay tiempo para eso". Es tu compromiso número uno. Como te conté en otra ocasión, el aseguramiento de la calidad acelera realmente la entrega del software, así que es un deber hacerlo durante todo el ciclo.
La estrategia de aseguramiento debe incluir actividades para encontrar defectos tan rápido como se producen y prevenirlos siempre que sea posible. Analiza con tu equipo el comportamiento que han tenido en cuanto a la manifestación de los defectos para empezar a introducir algunas de las prácticas que te describí.
En donde necesiten ayuda, no duden en contactarme
¡Hasta la siguiente ocasión!
¡Coméntame con un emoji en este artículo y te regalo mi Guía para Escribir User Stories!
¿Quieres implementar estas mejoras, pero no sabes cómo? Te presento dos alternativas:
Una consulta profesional de 1 hora, para discutir problemas individuales y encontrar respuestas.
¡Únete al grupo de facebook para compartir ideas con otros profesionales de Élite!
😁
Saludos.