Parte Uno: Construyendo una Base Sólida de Aseguramiento de Calidad
Este artículo es parte de una serie titulada «Crónicas de QA», donde presentamos nuestra experiencia en la mejora de las prácticas de Aseguramiento de Calidad (QA) en un entorno de desarrollo de productos de software. Si bien nos centramos en la experiencia del mundo real, creemos que estas prácticas pueden y serán reutilizadas en otros proyectos. En esta serie, presentaremos las diferentes estrategias que implementamos para mejorar la práctica de Aseguramiento de Calidad en un equipo de desarrollo de software que trabaja en la creación de un producto digital para un cliente externo. Este es un escenario típico para nosotros, donde construimos equipos de ingeniería para clientes externos.
Hace tres meses, cambié mi sombrero de gerente por unos auriculares de tester, sumergiéndome nuevamente en las trincheras como Líder de QA. Después de dos años liderando el equipo, me encontré de nuevo en la primera línea, listo para abordar un nuevo desafío. El equipo al que me unía estaba luchando contra problemas tanto de calidad como de velocidad. Además, algunas preocupaciones individuales de rendimiento burbujeaban bajo la superficie. Estaba claro que este proyecto no sería un paseo por el parque, pero yo prospero en el meollo de las cosas.
Con ganas de comenzar, inicié el proceso de incorporación. Al entrar en el proyecto, me encontré con un obstáculo: la documentación del proceso del equipo no estaba a la altura. Los documentos no se completaron, faltaban algunas secciones y, en algunos casos, la información no era suficiente, lo que me dejaba con un conocimiento insuficiente para hacer mi trabajo de manera efectiva. Esto produjo un efecto dominó que afectó al equipo. Las tareas se completaron al azar y los líderes no pudieron evaluar con precisión quién se ajustaba mejor al proyecto. Este sistema defectuoso obstaculizó el rendimiento de todos.
Las causas de estos problemas fueron múltiples, pero un problema evidente fue la falta de una estrategia de pruebas. A pesar del entusiasmo del equipo, el proceso de prueba carecía de una dirección clara. En cambio, todo el proceso de calidad se basó en un documento de alto nivel que describía algunos puntos de prueba. Esta ambigüedad abrió la puerta a desviaciones de las mejores prácticas y dejó a todos sin claridad sobre el rol de los ingenieros de control de calidad en las reuniones, la documentación de casos de prueba, la comunicación y la colaboración general. El equipo también desarrolló prácticas inconsistentes, y las pruebas se volvieron dependientes de las negociaciones individuales entre desarrolladores e ingenieros de control de calidad. Esto creó un sistema de favoritismo, eludiendo los procedimientos documentados y fomentando la falta de transparencia.
Esta fue una situación desafiante de abordar, ya que era necesario mejorar tantas cosas diferentes. Sin embargo, lo vi como una oportunidad para construir un equipo más fuerte y transparente, y una base para otros equipos en la empresa. Para ello, implementé con el equipo las siguientes estrategias:
1. Adoptar la comunicación abierta
Siendo parte de un equipo, las acciones fueron definidas e implementadas por todos, no solo por mí. Animamos activamente al equipo a tener todas las conversaciones en canales públicos donde todos los miembros del equipo y los representantes del cliente tuvieran visibilidad.
Para eso, decidimos predicar con el ejemplo, a veces haciendo preguntas cuya respuesta ya conocíamos, provocando discusiones y sacando a la luz problemas ocultos. Además, impulsamos al equipo a trasladar las conversaciones de los canales internos a aquellos en los que el cliente tenía visibilidad. De esta manera, pudimos identificar los problemas de manera proactiva, brindar al equipo soluciones adecuadas y oportunas, y asegurar al cliente al brindar visibilidad sobre la solución de los problemas identificados. Además, el equipo de Aseguramiento de Calidad comenzó a notificar por Slack cada vez que se tomaba un ticket para pruebas, y el hilo se actualizaba con cualquier pregunta que pudiera tener el ingeniero de control de calidad y/o el resultado del ticket.
2. Reconstrucción del conjunto de casos de prueba
Nos embarcamos en la misión de volver a documentar meticulosamente todos los casos de prueba existentes. Esto resultó en un conjunto conciso y bien escrito de casos de prueba enviados al cliente para su revisión. Decidimos solicitar su revisión por dos razones. Queríamos asegurar la claridad de los casos de prueba, permitiendo al cliente proporcionar observaciones valiosas y confirmar la cobertura de funcionalidades críticas, y en segundo lugar, su aporte sirvió como una valiosa verificación de cordura, ayudándonos a identificar cualquier brecha potencial en nuestra estrategia de pruebas.
3. Integración de las actividades de Aseguramiento de la Calidad con UX
Esta estrategia introdujo un elemento revolucionario: la participación directa del equipo de Aseguramiento de la Calidad en las reuniones de presentación de características de UX. En estas reuniones, los diseñadores de UX presentan cada nueva característica y discuten la lógica detrás del diseño propuesto con los representantes del cliente, los ingenieros de software y ahora, también con los ingenieros de control de calidad. Este enfoque proactivo desbloqueó varios beneficios.
El primero es la obvia detección temprana de errores, ya que al participar en los requerimientos durante la fase de diseño, los ingenieros de control de calidad ahora pueden identificar pasos faltantes en las nuevas funcionalidades, así como conceptos erróneos sobre el comportamiento del sistema existente. El segundo beneficio proviene de la detección de problemas ocultos, ya que esta participación temprana también arroja luz sobre errores que podrían haberse pasado por alto debido a la falta de comprensión sobre las decisiones de diseño específicas y su lógica subyacente. El tercer beneficio proviene de un diseño proactivo de casos de prueba, lo que nos permite comenzar a diseñar los casos de prueba desde un momento temprano, con tiempo para encontrar los mejores enfoques. Si bien esta práctica no está completamente implementada, ya vemos el potencial para que los ingenieros de control de calidad diseñen casos de prueba incluso antes de que se finalicen las estimaciones de desarrollo. Esto les proporcionaría una comprensión más clara del alcance y los capacitaría para planificar su enfoque de pruebas de manera más efectiva. Dado que esta ha sido una experiencia muy enriquecedora, interactuando directamente con un público tan diverso, la detallaremos más en un futuro artículo.
¡Mantente conectado!
4. Migración de la automatización de pruebas de Selenium a Playwright
Necesitábamos un framework más rápido para lograr los objetivos que nos habíamos marcado. Por el momento, aunque no hemos alcanzado el conjunto necesario de casos de prueba automatizados, ya lo tenemos como parte de una pipeline automatizada. Configuramos un conjunto de pruebas de humo que se ejecuta después de cada implementación en los entornos de Pruebas de Aceptación de Usuario (UAT) y Producción. Además, también se ejecuta para cada Pull Request (PR) que crea el equipo de Desarrollo como una verificación que debe pasar antes incluso de ser revisada por pares. Esto, junto con la asignación de la responsabilidad de fusión e implementación a QA, ha permitido mantener estable la rama principal. Ahora que tenemos un entorno de Producción en vivo, podemos lanzar dos veces por semana, dedicando solo medio día a cada esfuerzo de lanzamiento.
Conclusión y próximos pasos
Si bien hemos recorrido un largo camino, con mejoras visibles, creo que esto es solo el comienzo. Nuestro objetivo es tener un proceso completo de extremo a extremo que nos permita lanzar a producción cada ticket tan pronto como el equipo de Aseguramiento de la Calidad lo apruebe, y estoy seguro de que estamos en el camino correcto para lograrlo. Lo mantendremos informados sobre los resultados de este caso en un par de semanas para que todos ustedes sepan cómo estamos y qué otros cambios aplicamos a nuestro proceso.
Parte Dos: Unir Aseguramiento de Calidad y UX para mejores resultados