Cómo ofrecer control de calidad con rapidez

Cambiamos el control de calidad por una asistencia de calidad

Laura Daly Laura Daly

Es difícil adaptar los métodos de prueba tradicionales a la cultura ágil. Los equipos se sienten obligados a alcanzar el equilibrio entre la calidad del producto y la velocidad de lanzamiento.

Para combatir estos problemas, en Atlassian hemos introducido un enfoque distinto en las pruebas ágiles que se conoce como Quality Assistance. En lugar de crear un equipo de prueba independiente encargado de la calidad, un equipo pequeño de ingenieros de Quality Assistance instruye y entrena los métodos de prueba sostenibles en el equipo de desarrollo. Obtén más información sobre esta transformación y cómo realizar lo siguiente:

  • Crear una cultura de calidad
  • Pasar la responsabilidad de volver a realizar una prueba a los desarrolladores
  • Evitar errores, no detectarlos

Preguntas y respuestas

Lee las preguntas y respuestas de esta presentación para obtener más información sobre cómo un equipo de 65 ingenieros crean y envían de forma rápida un producto de alta calidad con solo seis ingenieros de QA.  

P1: ¿Cuánto tiempo le lleva a un desarrollador habituarse a esta forma de pensar?

R1: Es más difícil cambiar la cultura de todo un equipo que transformar a las personas. Hemos tardado cinco años en conseguir que el equipo de Jira Software alcance la mentalidad de calidad que tiene hoy, pero cada desarrollador nuevo no tarda demasiado en ponerse al día. Rápidamente, adopta la misma mentalidad que sus compañeros desarrolladores existentes, y pronto adquiere las habilidades de prueba gracias al emparejamiento y los talleres. La parte más dura, quizás, sea asimilar todo el conocimiento acerca de los riesgos y el producto. En esto pueden tardar años, aunque tratamos de mitigarlo mediante el intercambio de conocimientos en los lanzamientos y las demostraciones de QA.

P2: ¿Siguen siendo necesarios los casos de prueba? ¿Se utilizan solo para pruebas de regresión o automatizadas?

R2: Los casos de prueba manuales generados por script no entran, en absoluto, en nuestra estrategia. Si una prueba es solo una "verificación", es decir, un conjunto de pasos predefinidos y una afirmación definida, nos parece más eficiente y menos propenso a errores que la ejecute un ordenador en lugar de un humano. Si una prueba es realmente una prueba, que requiere un pensamiento crítico, libertad para investigar y una evaluación de riesgos, nos parece mejor ejecutarla como parte de una prueba exploratoria con el fin de incluir esa libertad e inteligencia en la prueba.

P3: Los desarrolladores suelen ser más costosos que los evaluadores. Si utilizamos desarrolladores como evaluadores, ¿no estaremos haciendo un uso ineficiente del presupuesto/de la mano de obra?

R3: Totalmente, utilizar a desarrolladores como evaluadores para ejecutar un paso de prueba distinto es costoso y desperdicia el tiempo del desarrollador. Pero contar con un paso de prueba diferente —incluso uno ejecutado por evaluadores— también es caro y desperdicia el tiempo del desarrollador. Cada vez que una historia o bug es devuelto por evaluadores a los desarrolladores, no solo hablamos de los costes de pruebas, sino también del coste de un desarrollador. Al reducir la tasa de rechazos del 100 % al 4 %, hemos ahorrado muchísimo tiempo de desarrollo que se estaba desperdiciando en volver a elaborar historias y en solucionar bugs absurdos antes del lanzamiento. Hemos ahorrado el tiempo invertido en investigación, generación de informes, trazabilidad, evaluación, reproducción y corrección de los bugs detectados internamente. Además, el código está diseñado desde cero de una forma más comprobable, ya que los desarrolladores saben que serán ellos mismos los que tengan que realizar las pruebas posteriores. Nuestra fase de desarrollador en pruebas o DoTing (del inglés "Developer-on-Testing") resultó ser un paso intermedio en el camino de impulso de la calidad aguas arriba, de modo que pudimos quitar por completo del proceso el paso de prueba independiente. Fue una inversión temporal que, sin duda, ha valido la pena.

P4: Disponemos de desarrolladores y evaluadores de QA en varias zonas horarias. ¿Funcionaría este modelo únicamente en la misma zona horaria? ¿Cómo trabajas con los equipos remotos?

R4: Hemos proporcionado asistencia remota de calidad a los equipos de Polonia y Vietnam, con el ingeniero de QA afincado en Australia. No es tan eficaz como tener a un ingeniero de QA cualificado in situ, pero una parte importante de ser un buen ingeniero de Quality Assistance consiste en establecer una relación personal con los desarrolladores. Un ingeniero de QA remoto suele quedar desinformado fácilmente, y resulta mucho más difícil medir la cultura global del equipo. Sin embargo, hemos podido llevar a cabo demostraciones de QA, lanzamientos de QA y sesiones de emparejamiento de forma remota y con todas las garantías mediante videollamada; simplemente llamamos desde la máquina del desarrollador a la del ingeniero de QA y compartimos la pantalla.

P5: ¿Se basan las notas de QA en las historias o creas una base de conocimiento a partir de dichas notas de QA? ¿Cómo tratas los riesgos recurrentes?

R5: Las notas de QA se basan en las historias, por lo que son, normalmente, los ingenieros de QA los que detectan los patrones de riesgos recurrentes. Esto se ha vuelto más difícil con los años a medida que nuestro equipo de QA de Jira Software ha ido creciendo, ya que no es preciso que cada ingeniero de QA sepa necesariamente lo que están haciendo los demás. Hasta ahora, hemos mitigado el problema con reuniones semanales de intercambio de ideas y con páginas wiki donde podemos hacer un seguimiento de los riesgos habituales o inesperados. Estamos llegando al punto en el que deja de existir una ampliación posible. Ahora, estamos trabajando en una base de conocimiento más estructurada con una base de datos de reglas que se ejecutan con cada commit. Así que, por ejemplo, si observa que estás utilizando el objeto de usuario en tu código de Jira Software, la base de datos de reglas añadirá un comentario al tique diciendo lo siguiente: "El objeto de usuario puede ser nulo si el usuario actual es anónimo; asegúrate de que estás manejándolo de forma correcta". De este modo, lograremos sacar fuera el conocimiento de los responsables de QA y, en el mejor de los casos, hasta sustituir la necesidad de demostraciones de QA y lanzamientos. ¡Esto sería de gran ayuda!