_716a2fbe-6bf9-420b-ab91-b0efe8aa48b5
Opinión
30 de noviembre 2023

¿Por qué aplicamos el concepto de calidad en lo cotidiano y cuesta tanto en proyectos SW?

8 minutos de lectura

Imaginemos una situación cotidiana: Un día, recibes la preciosa noticia de que vas a tener un bebe ¡¡¡Qué noticia tan feliz!!!. Desde el primer momento que nos dan la noticia nos asaltan las dudas, nervios, empezamos a pensar cómo será eso de ser padre/madre, en comprarle su primera muda, la decoración de su habitación, si el piso en el que vivimos ahora es lo suficientemente grande para vivir con el nuevo miembro de la familia… Pero antes de todo esto, han de pasar 40 semanas. Unas semanas que van avanzando poco a poco, hasta la primera ecografía, dónde confirman la existencia del feto (o de los fetos). Después, cada X semanas, ecografías de control para darnos la noticia de si es niño o niña, si va midiendo/pesando lo correspondiente a su percentil, si se está gestando en perfectas condiciones de salud,… y así hasta que finalmente llega al mundo. 

En el contexto anterior, ¿Se le ocurriría a alguien esperar a la semana 40, al momento del nacimiento, sin hacer revisiones previas, para dejarlo todo al último momento? Claramente la respuesta es un rotundo NO, por tanto, ¿Porqué sí que lo hacemos en la gran mayoría de productos software? Y algunos, seguramente diréis: “Claro, pero no es comparable entregar software, con el nacimiento de un bebé”. Correcto, sin embargo, también podemos llevar esta analogía a cualquier otro escenario de nuestra vida: la compra de un coche, un piso, una casa, la elaboración del power point que nos manda hacer nuestro jefe, un mueble hecho a medida, …

¿Porqué dejamos para la última etapa del proceso las labores de previsión y control en el desarrollo de software?​

Hay muchos factores. Sin duda, el primero es el factor histórico: Al menos en España, el QA/testing es una disciplina relativamente nueva. Ahora hablamos de testers, QA, … (hablamos sobre los roles en un post anterior) pero hace relativamente poco , unos 15 años, no era tan habitual tener equipos de QA. Sobre todo era común en empresas que hacían software crítico (medicina, aviación, …), teniendo equipos de testing trabajando en silos desconectados de los equipos de desarrollo.
Poco a poco se ha ido instaurando la idea de que es importante tener equipos de testing probando ese software codificado por desarrollo. Y más recientemente se introdujo la idea del Quality Assurance, que evoluciona el clásico rol de Tester.

Factores empresariales: En la actualidad, las empresas se encuentran bajo una enorme presión para destacarse frente a la competencia, teniendo que ofrecer productos y servicios con rapidez y agilidad. Esto provoca en los equipos la sensación de “deliveritis” -entregar, entregar y entregar-, gestionando los posible errores mediante técnicas de “Shift-right”, arreglando estos en producción tan pronto se detecten. No es que el shift-right y sus técnicas asociadas sea malo, al contrario, pero habitualmente no se usa de la manera más adecuada. Un ejemplo claro son las técnicas de A/B testing: Más veces de las que deberían, producto poniendo en producción funcionalidades al 0% de usuarios porqué hay problemas sin solucionar. Sin embargo, para ellos la funcionalidad ya “está” en producción.

Falta de conocimiento y formación: Cuántas veces hemos oído aquello de “Yo quiero un software sin bugs”, claro síntoma que falta formación en temas de calidad, no sólo tanto a nivel de desarrollo/producto, pero sí a nivel top management. 
Además, otra frase que seguramente, muchos de vosotros habréis oído es el clásico “No tengo tiempo para esto”, en clara alusión a esas técnicas/actividades de test que proponemos y el equipo no estar receptivo al entender que son tareas que pueden “retrasar la entrega”.

¿Qué podemos hacer para revertir la situación y pensar en calidad desde el principio de cualquier proyecto?

Formación y comunicación a todos los niveles: La calidad no viene de tener un backlog libre de bugs o de detectarlos en las pre-release a producción mediante la ejecución de tests: Los bugs sólo son la expresión de falta de unos requerimientos claros, toma de decisiones técnicas no siempre acertadas debido a la presión para el delivery,… y la manera de reducirlos es construyendo desde el principio con calidad: Buenos requerimientos, buenas arquitecturas de software, código limpio, buenos tests,… y todo ello se consigue involucrando a todo el equipo en la toma de decisiones desde el principio.
Además, es importante comunicar y formar de manera eficiente al equipo directivo en la importancia de la calidad. Estudios recientes realizados por consultoras de prestigio como son Gartner, Deloitte y Capgemini han demostrado que las empresas que  entregan un producto/servicio con un nivel elevado de calidad reduce en un 25% los costes asociados al desarrollo, incrementa un 20% la satisfacción del cliente y tienen un 30% más de probabilidad de ganar cuota de mercado en sus respectivos contextos.

Gestión eficiente de la deuda técnica/bugs:  La deuda técnica se genera por diferentes motivos, uno de los principales, es por la presión para incrementar la productividad. Esto provoca que se entre en el denominado “círculo vicioso”:  Querer incrementar la productividad, aumenta la deuda técnica, lo que provoca un código de menor calidad, y contribuye a una menor productividad, puesto que desarrollo se pasará gran parte del tiempo solucionando problemas/bugs.
Para evitar esto, esta no debe ser tratada con un tiempo específico cada X iteraciones, sino que ha de tratarse como una tarea recurrente en el día a día tomándose tiempo para pensar las mejores soluciones a problemas de código, arquitectura, y por supuesto, la resolución de bugs. Indudablemente siempre va a haber deuda técnica, pero la idea es que sea la menos posible.

Buenas prácticas de testing y calidad: Tener profesionales de Calidad en las empresas ayuda (respetando las empresas que deciden prescindir de estos profesionales) a que se instauren buenas prácticas no sólo de testing, si no de calidad. La calidad no sólo es probar o automatizar pruebas. Además de esto, trata de crear código mantenible, arquitecturas escalables,… y esto es trabajo de todo el equipo.

Organización: Otros de los puntos importantes. Hay que entender cómo organizar/gestionar los recursos humanos: ¿Equipos de Calidad transversales? ¿QA embebido dentro de cada uno de los equipos de desarrollo -lo que comúnmente llamamos Feature Teams (Squads) Cada empresa y cada equipo es diferente, lo que funciona en una empresa puede no funcionar en otra, por lo que hemos de entender el contexto de cada una de ellas, skills/seniority de los developers para adecuar la estructura organizativa del equipo de Calidad -y por supuesto también de desarrollo y producto-.

Soft Skills: Esas capacidades interpersonales que son imprescindibles para relacionarse con desarrollo, producto y demás stakeholders. Dichas habilidades nos ayudarán a darles feedback, a comunicarnos con ellos, a empatizar, a dar nuestro punto de vista (estemos de acuerdo o no) de una manera respetuosa,…. Sin duda, todas esas habilidades nos ayudarán a infundir la calidad dentro de los equipos y de la empresa desde el comienzo del proceso.

En estos y muchos otros puntos entraremos más en detalle en futuros artículos.Hasta entonces, ¿qué opináis?

Recomendados

¿Por qué aplicamos el concepto de calidad en lo cotidiano y cuesta tanto en proyectos SW?

Reflexionemos juntos sobre situaciones cotidianas en que todo se realiza con previsión, mimo y...

Testing Exploratorio: breve guía para lograr el éxito en tus sesiones

El testing exploratorio es probablemente uno de los temas que más confusión genera en el mundo del...

La prostitución del término QA

En el dinámico mundo de la tecnología y el desarrollo, los roles relacionados con el testing y la...

La evolución de los títulos de los roles relacionados con testing y calidad

Opinión 8 de noviembre 2023 La evolución de los títulos de los roles relacionados con testing y...