Crónicas de QA, Parte Tres: Recogiendo las Recompensas de la Transformación
Si no has visto ningún post anterior, te recomiendo que los revises para un contexto más amplio. Aquí están los enlaces:
- Parte Uno: Construyendo una Base Sólida de Aseguramiento de Calidad (gbh.tech)
- Parte Dos: Unir Aseguramiento de Calidad y UX para mejores resultados (gbh.tech)
Han pasado tres semanas desde que devolví mi sombrero de gerente después de este viaje lleno de insights. Esta fue la clase de experiencia que cambia tu perspectiva sobre cómo abordar problemas cotidianos y, en este caso, quiero compartir el impacto de los cambios implementados en este y otros proyectos.
Colaboración entre QA y el resto del equipo
El equipo de QA pudo recuperar la confianza del equipo implementando un proceso de prueba consistente que se enfoca en asegurarse de que todos tengan la información que necesitan cuando la necesiten. En otras palabras, la documentación es clara y refleja lo que el equipo hace, no al revés. Además, las pruebas automatizadas se ejecutan en los momentos definidos. Siempre están disponibles y funcionales, permitiendo al equipo confiar en ellas para decidir si un cambio está listo para pruebas adicionales del ingeniero de QA.
Adicionalmente, el equipo se siente lo suficientemente confiado como para probar nuevas implementaciones graduales de shift-left, lo que significa que pueden manejar cualquier problema que pueda surgir al hacer algo nuevo.
El área de QA
Concluimos que el proceso actual de revisión de QA necesita ser mejorado. Durante esta evaluación, yo verificaría la documentación de un proyecto en el lado de QA y su automatización para identificar oportunidades de mejora y dar esa retroalimentación con recomendaciones pertinentes al equipo. Sin embargo, estas banderas usualmente resultan de algo más, por lo que necesitamos tratar estas banderas como alertas de un problema más significativo, identificar la causa raíz y guiar al equipo hacia una solución.
Automatización de pruebas
Por mucho, la mejora más destacada lograda fue la implementación temprana de la automatización de pruebas, ya que pudimos probar y demostrar que ahorraría muchas horas para todo el equipo. Las pruebas de humo automatizadas que se ejecutan para cada Pull Request (PR) han detectado un número increíble de bugs antes de que el ticket sea enviado para revisión de código, aumentando la velocidad del ciclo de retroalimentación con el equipo de desarrollo y liberando mucho tiempo para que el equipo de QA agregue más casos de prueba a la regresión completa y haga más pruebas exploratorias en la aplicación.
Este smoke suite no necesita tener docenas de casos de prueba; de hecho, no debería tener más de 5 o 6 en tu aplicación promedio de inicio. Lo que importa es cuáles eliges y cuán fácilmente un desarrollador puede identificar y depurar el problema si hay alguno. Si te tomas el tiempo para hacerlo bien, te liberará mucho tiempo para hacer más de las cosas que entregan valor directo a las partes interesadas.
Trabajo en equipo
Finalmente, entendimos que necesitamos acercar todas las disciplinas que intervienen en el flujo de trabajo de desarrollo y asegurarnos de colaborar desde una perspectiva informada, sabiendo qué se debe o no se debe esperar que maneje cada rol y asegurándonos de que todos siempre estemos de acuerdo y seamos conscientes de esas responsabilidades. Esta es la única cosa que impulsará los cambios más significativos en todas las áreas, ya que necesitaremos descubrir e implementar explícitamente en nuestros procesos cómo podemos ayudarnos mutuamente a entregar el máximo valor posible.
Conclusión
A menudo nos convencemos de que no podemos lograr ciertas cosas, que solo las grandes corporaciones o los equipos muy maduros pueden tener pipelines automatizados decentes, enfoques de shift-left y probar cosas nuevas, pero a veces, es la implementación de esas cosas lo que permite a una empresa y un equipo crecer exponencialmente.