Dalia Trujillo
Líder en calidad y desarrollo de software. Hacemos que las empresas aumenten dramáticamente su calidad y velocidad de desarrollo, a través de Enjisst (Plataforma) y PAREX (Metodo de agilidad pragmática)
21 de mayo de 2020
El tema de pruebas ha tenido evolución dramática a lo largo de los últimos años, según lo he visto y experimentado desde que inicié a trabajar en proyectos de software. Hace 28 años, cuando empecé mi experiencia en proyectos de software, había claridad que la metodología a aplicar era cascada, y se creía que el aspecto clave del éxito del proyecto era que los requerimientos estuvieran muy bien definidos; de forma que lo único que se debía hacer en la etapa de pruebas era validar el correcto cumplimiento de esos requerimientos. Sin embargo, en ese momento pruebas no era rol especial, más bien era una etapa donde se validaban los requerimientos, y no había conciencia de lo extenso y profundo que puede ser la validación del software.
Hace unos 20 años, por lo menos en Colombia, empiezan algunas organizaciones a crear conciencia de la necesidad del rol, y hace 10 años ya se podían encontrar en varias empresas las áreas de Calidad, pruebas, QA o el nombre que fuera más apropiado para la empresa.
Si bien, las técnicas de calidad son mayores en las organizaciones, lo que redunda en principio, en mayor calidad para el software, fue implementado de forma taylorista , por silos, en donde después de hacer el desarrollo se pasa a una etapa de validación, para “filtrar” los errores y que no pasen a producción.
Al igual que en cualquier aprendizaje, el medio primero aplicó las técnicas básicas para entender los pasos necesarios para producir software con mayor calidad. Se crearon mecanismos para que las personas entendieran esas técnicas, lo que se puede encontrar en los entes certificadores de conocimiento sobre pruebas, y se ve mucha mayor evolución de conciencia en los aspectos y niveles funcionales y no funcionales que debe incluir la correcta y completa validación del software, por medio de pruebas y de aseguramiento de la calidad.
Sin embargo, a pesar de que las propuestas metodológicas han cambiado, y hay mayor enfoque hacia el manejo iterativo, como puede ser Scrum que trabaja por sprints, todavía no se ha comprendido el impacto en lo que significa tanto en la forma de probar como en la interacción entre el equipo.
Voy a explicar mi punto basado en una gráfica de Scaled Agile Framework (SAFe) que lo permite visualizar de forma clara:
En varias empresas he encontrado la forma de trabajo que SAFe llama “cascada entre iteraciones” (primera gráfica). Por eso se refieren a sprints de pruebas, sprints de desarrollo e incluso sprints de diseño. Si bien, puede ser una forma válida de trabajo, es importante aclarar que difiere de los principios ágiles, en donde según refiere el Manifiesto Ágil: “Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible”; es entregar software, no es desarrollar software.
En un número mayor de empresas he encontrado que implementan “cascada dentro de las iteraciones” (segunda gráfica), que era la forma que proponía RUP ( Rational Unified Process), como forma de trabajo. Es una ganancia mayor con respecto a la primera porque al final de cada iteración se puede tener un entregable claro, ejecutable y probado.
Pero es el manejo de “iteraciones de funciones cruzadas” (tercera gráfica) la que permite implementar principios de Scrum tan importantes como es Timeboxing y entrega de valor basada en priorización.
Este manejo implica retos importantes como es el saber dividir las funcionalidades de forma que se pueda desarrollar por requerimientos tan cortos que puedan estar diseñados, desarrollados y probados en pocos días, que la automatización de pruebas esté implícita en el trabajo, porque la ejecución continua y repetitiva de pruebas será parte del día a día, y que el trabajo colaborativo sea la premisa, evitando desgastes entre los roles, que muchas veces se presentan entre desarrolladores y probadores.
Bibliografía:
- SAFE Reference Guide 4.0. Dean Leffingwell
- The Rational Unified Process, An introduction. Phillippe Krutchen