Parte Dos: Unir Aseguramiento de Calidad y UX para mejores resultados
Si no ha visto la publicación anterior, le recomiendo que la consulte para obtener un contexto más amplio. Aquí está el enlace: Parte Uno: Construyendo una Base Sólida de Aseguramiento de Calidad (gbh.tech)
Hace cinco meses, cambié el sombrero de gerente por los auriculares de un tester, sumergiéndome de lleno en las profundidades de un equipo con desafíos. En la publicación anterior, navegamos a través de los hallazgos durante los primeros meses y los cambios iniciales que implementamos para mejorar el rendimiento y la calidad del equipo. Ahora, permítanos hablar un poco más sobre un paso crucial en el enfoque de cambio a la izquierda que estamos siguiendo: forjar una conexión sólida entre el control de calidad y la experiencia del usuario (UX).
Enfoque previo
Inicialmente, la única interacción entre el equipo de control de calidad y el equipo de UX era una sesión de estimación con el equipo de desarrollo. Ese era el momento en que los tickets recién diseñados se presentaban a todo el equipo por primera vez. Se hacían preguntas sobre la implementación de estos cambios, y la discusión sobre cada ticket se centraba en comprender cómo implementarlo en el código base actual. El equipo de control de calidad también participaba en la estimación para proporcionar información sobre las pruebas y ajustar las expectativas, ya que tenemos un mayor contexto general del esfuerzo necesario para completar tickets anteriores.
Si bien esto fue bueno, no fue suficiente. Primero, no nos proporcionó toda la información y el tiempo para diseñar casos de prueba. En segundo lugar, el tiempo necesario para ejecutarlos contra el diseño de UX ya era corto. Por último, documentarlos para que el equipo de desarrollo los tuviera disponibles para el momento en que recogían el ticket también era un desafío.
Nuestro objetivo era un cambio a la izquierda, ya que aumentaría la calidad general del producto. Por lo tanto, observamos el proceso actual de UX para ver en qué punto el equipo de control de calidad podría involucrarse sin consumir demasiado tiempo y sin interrumpir al equipo de UX. Allí, encontramos que la reunión de presentación de funciones era la candidata ideal para el puesto. Durante esta reunión, el cliente discute con el equipo de UX los diseños presentados, solicita cambios, solicita cosas nuevas y explica en detalle el razonamiento comercial detrás de las funciones solicitadas.
Esto fue fantástico para nosotros porque, mientras se llevaba a cabo esta discusión, pudimos identificar casos de prueba, proporcionar información sobre el comportamiento actual y las limitaciones de la lógica empresarial existente, y, en última instancia, tener una comprensión más profunda de las características y su propósito. Además, esto generalmente sucedía mucho antes de que hubiera siquiera un ticket en el backlog. Entonces, ahora teníamos suficiente tiempo para documentar los casos de prueba y agregarlos a los tickets cuando se creaban.
Extendiendo el puente
Como este equipo está utilizando Figma para los diseños de UX, me llamó la atención que permite agregar atributos a los elementos, por lo que podemos agregar los ID de prueba al diseño, y me encantó esta idea por dos razones:
- Los ID de prueba están en su lugar y disponibles desde el principio. El equipo de desarrollo puede implementar todo lo que necesitamos para automatizar los casos de prueba. Además, sabemos qué esperar y comenzamos a construir la automatización al mismo tiempo o incluso antes de que el desarrollador comience a trabajar en los cambios.
- Esto funciona como un proceso de control de calidad para el diseño de UX. Este enfoque obliga a los ingenieros de control de calidad a observar cada pantalla y todos sus elementos en el diseño, lo que aumenta la probabilidad de detectar errores de diseño y de simular cada escenario que se automatizará con el diseño, dándole sentido antes de que se implemente.
Esta última parte aún está en proceso. Todavía necesitamos definir en qué punto y cómo llevaremos a cabo esta nueva tarea, pero el equipo está receptivo a la idea y ya se han programado reuniones para discutir este enfoque.
Creo que este podría ser el último cambio importante que debemos realizar en nuestro flujo de trabajo actual para lograr nuestro objetivo. Una vez implementado, solo necesitaremos ajustar los detalles y acostumbrarnos al enfoque. En un par de semanas, publicaremos la última parte de esta serie para detallar todo lo que logramos con estos cambios y lo que aprendimos de todo esto.
¡Estén atentos a las novedades!