Calidad Somos Todos

Hace poco tiempo tuve la ocasión de poder asistir a una charla del equipo de ATLASSIAN, en la cual proponían una visión diferente del trabajo del QA, pasaban de ASSURANCE a ASSISTENCIAL. Me pareció una apuesta muy acertada y que coincidía con lo que llevaba tiempo pensando. Ahora quisiera compartir estas líneas para que valoréis el nuevo enfoque propuesto.

Primeramente, resulta difícil adaptar los métodos tradicionales de pruebas a una cultura ágil, los equipos se sienten forzados a tener un producto de calidad en un tiempo determinado(sprint). Como consecuencia siempre se verá alterado el alcance, la velocidad o la calidad del producto.

Por otra parte, durante años el modelo que se seguido ha sido el de cascada, teniendo como detrimenta las siguientes implicaciones:

- Los proyectos raramente siguen el proceso lineal tal como se definía originalmente el ciclo de vida.

- El cliente no suele establecer al principio todos los requisitos necesarios.

- El producto se ve cuando ya está finalizado, lo cual provoca una gran inseguridad por parte del cliente que quiere ir viendo los avances en el producto.

- Existen requisitos que no se hayan tomado en cuenta desde el principio. Los errores de análisis y diseño son costosos de eliminar, propagándose a las siguiente fases con el efecto conocido como bola de nieve.

- El producto es entregado al equipo de QA al final del desarrollo, donde se encontrarán los todos los bugs y se realizará el típico peloteo de incidencias, prologándose en el tiempo la entrega del producto.

Actualmente, el modelo Agile propone un enfoque donde los requisitos y soluciones evolucionan con el tiempo, dependiendo de la necesidad del proyecto. El modelo ideal sería que por cada parte del proyecto realizada, a continuación se pudiera probar por el equipo de QA, detectando los bugs lo más rápidamente posible, mientras se continúa desarrollando.

Pero todos sabemos que no es posible, lo que sucede realmente es que el tiempo dedicado al desarrollo abarque parte del tiempo para ser probado, hasta el punto de que pueda absorber todo el tiempo estimado del QA.

Para combatir todos estos problemas la idea sería proponer un enfoque diferente para las pruebas ágiles, conocido como Asistencia de Calidad. En lugar de tener un equipo de pruebas independiente, se crea un pequeño equipo de ingenieros de asistencia de calidad, utilizando métodos de pruebas como si fueran coaches de todo el equipo de desarrollo. El equipo debe centrarse en la prevención en lugar de la detección.

Con ello lo que deseamos introducir en el equipo la idea de:

- Crear una cultura de calidad. - Empuje de la responsabilidad de probar de nuevo a los desarrolladores. - Prevenir los Bugs no detectarlos.

Beneficios del modelo de asistencia de calidad

Calidad: Los desarrolladores que dominan las pruebas no sólo aumentan la eficiencia y la capacidad de sus equipos, sino que también escriben software de mayor calidad.

Eficiencia: La prevención de errores antes de que se escriben significa que el tiempo y el esfuerzo para corregir errores o volver a escribir código adicional se reduce. Los desarrolladores pueden decidir cuando su trabajo está listo para su entrega, en lugar de ciclos desalentadores de código-test-retest de la reanudación.

Independencia: Cuando las pruebas las son compartidas con los desarrolladores, las personas que sienten pasión por la calidad, se sienten como grandes probadores, pueden centrarse en resolver las causas fundamentales de los problemas de calidad además de descubrir sus síntomas.

La implementación de una asistencia de calidad

Cambio de los procesos de calidad de un equipo existente requerirá tiempo y esfuerzo. Todos los desarrolladores en el equipo deben tener un nivel suficiente de formación para que sepan cómo probar con eficacia. Basta con decir que "ahora los desarrolladores hacer la prueba" aumentará el riesgo de problemas de calidad. Pero no se desespere: hay varias maneras de mitigar esto:

Blitz Testing: Pidiendo a todo el equipo a participar en una sesión de pruebas, es una forma divertida para que los equipos comprueben que son de seguros respecto a las características que se están implementando. Pueden proporcionar retroalimentación a partir de una variedad de usuarios, y detectar errores y otros problemas antes de un lanzamiento. Si las pruebas relámpago están descubriendo constantemente problemas críticos, mostrará que la historia de las pruebas de nivel que se realiza es insuficiente.

Dogfooding: La publicación de sus características inéditas en las instancias internas es una buena manera de validar que son útiles y fáciles de usar. Puede significar que los problemas se descubren, informaron y se fijaron antes de la función que se les entrega a sus clientes.

DoT: La asignación de un "desarrollador de prueba" es una buena manera de introducir a los desarrolladores a la idea de la prueba, mejorar sus habilidades y hacer explícito que la calidad es responsabilidad de todos. Se evita el problema de un ingeniero de control de calidad de ser el cuello de botella para el equipo.

Sin embargo, la dependencia a largo plazo sobre Doting es una señal de que un equipo no confía en las pruebas realizadas por el desarrollador que implementa la historia. Efectivamente, alguien es doble control de las tareas de pruebas que deberían haber sido hechas por el desarrollador original.

QA Kickoffs: El emparejamiento con los desarrolladores les anima a pensar de todos los riesgos y los casos extremos por adelantado, antes de que comiencen la implementación de la historia. Se pueden evitar problemas anteriormente haciendo una lluvia de ideas para llegar a resolver cualquier ambigüedad desde el principio.

Proceso de control de calidad Provisional

Medida que la transición hacia el aseguramiento de la calidad, el proceso de control de calidad puede ser algo como esto:

A medida que los equipos se vuelven más confiados en la capacidad de realizar nuevas características de alta calidad, se puede experimentar con la eliminación de algunas de estas etapas - probablemente el punto y etapas de prueba Blitz - para ciertas historias.

"La experimentación es la palabra clave aquí, sea paciente, iterar, y saber que el hecho de que estás en un viaje significa que estás en el camino correcto."