¿Cuál es la estrategia de prueba correcta en los equipos Agile Scrum / Kanban?

El problema es:

El equipo en el que estoy trabajando tiene una relación de 10 desarrolladores a 2 probadores, lo que significa que vamos a producir código más rápido de lo que se hace "Prueba".

Entonces, ¿cuál debería ser el enfoque correcto para rastrear actividades en tales escenarios de acuerdo con expertos ágiles?

Mi temor es que pronto llegue el día, cuando haya muchas cosas que se llamarán "Listo" en sprints anteriores (sin pruebas), pero cuando realmente se trata de pruebas, puede haber algunos defectos potenciales.

¿Cómo puedo seguir los esfuerzos sin problemas? ¿Deberían las pruebas ser parte de la "definición realizada"? ¿Cuáles son las trampas si no es así?

Según yo, es una especie de 'Cascada', ya que llamas historias "Hecho" antes de que se pruebe funcionalmente.

Sí, probar absolutamente debe ser parte de la definición de "Listo". Sin duda.

Desde un punto de vista puramente ágil, el enfoque correcto es que todos en el equipo contribuyan a redactar pruebas. El probador será el que coordine el esfuerzo, pero es responsabilidad de todo el equipo asegurarse de que el software se pruebe correctamente.

En primer lugar, una relación de 10: 2 es mala. Según la experiencia, una relación de desarrolladores 3: 1 o 4: 1 a probadores funciona bien. Por lo tanto, es probable que necesite al menos un probador más, de lo contrario, la acumulación de pruebas crecerá y nunca se eliminará, o se cortará en alguna parte.

Si prueba tareas en el próximo sprint, está implementando mini-cascada o "caída de scrum" a medida que separa las pruebas del desarrollo. Tienes razón en que las pruebas deberían formar parte de la definición completa. Si una tarea no se prueba, ¿cómo se puede declarar "terminada"?

Por lo tanto, el enfoque correcto sería:

1. Si es posible, agregue un probador al equipo, de lo contrario, haga que los desarrolladores realicen algunas pruebas (aunque probablemente no harán un trabajo tan bueno como un probador profesional).
2. Modifique su tablero scrum / kanban para incluir columnas "listas para la prueba" y "en prueba" y acuerde con el equipo que parte del flujo de trabajo debe tener todas las tareas en estos carriles.
3. Las tareas solo llegan a la columna "Listo" cuando han sido aceptables mediante pruebas.

Esto es bastante común, si no es típico. Para responder cuáles son varias preguntas:

• ¿Cuál debería ser el enfoque correcto para rastrear actividades en tales escenarios?
• ¿Se realizarán las funciones sin control de calidad pero con defectos?
• ¿Cómo puedo seguir los esfuerzos sin problemas?
• ¿Deberían las pruebas ser parte de la "definición realizada"?
• ¿Cuáles son las trampas si no es así?

Adoptaría un enfoque general que:

• permite a los evaluadores agregar valor
• les da autoridad
• maximiza su valor
• anima a la gente de QA a capacitar a los desarrolladores

y para hacer eso (y responder sus preguntas) yo haría:

• asegúrese de que puedan ingresar errores en un sistema de seguimiento de errores fácil de usar que también contiene características como Jira, Trello, Pivotal Tracker, etc.

• asegúrese de que estén capacitados para crear buenos informes de errores que describan:

  • pasos para reproducir
  • valores iniciales / de configuración
  • valores ingresados
  • capturas de pantalla cuando sea apropiado
  • registros del servidor cuando sea apropiado
• asegúrese de que vean los errores asignados, trabajados y completados.
• capacitarlos en mejores prácticas y enviarlos a conferencias.
• capacítelos en la programación y el uso de un marco de prueba.
• permítales enseñar a los programadores sobre buenos enfoques y mentalidad para las pruebas.

Además, sí, algunas funciones pueden realizarse sin control de calidad pero con defectos. A menudo encuentro que el control de calidad es un segundo par de ojos. A veces, este rol puede ser desempeñado por otro desarrollador. Personalmente, creo que esto encuentra algunos errores, pero no todos los que podría encontrar una mentalidad de control de calidad diferente.

La prueba debe ser parte de la realización, pero eso no significa que la persona de control de calidad tenga que hacer la prueba. Dada la escasez de recursos y un entorno ágil que evita las especificaciones que el control de calidad puede observar, el control de calidad debe participar en el aprendizaje del dominio de los usuarios, diseñar reuniones, reuniones de preparación de puntos, stand-ups, retrospectivas, etc.

En cuanto a la gran pregunta de la estrategia de prueba, use los cuadrantes de prueba ágiles para guiarlo:

                   |
      Integrated   |     Performance
_________________________________________
                   |     
           Unit    |     Exploratory

Es posible que los desarrolladores ya estén haciendo pruebas unitarias. Un área clave que QA puede agregar valor al cubrir es en las pruebas integradas y el uso de la automatización de la interfaz de usuario. Las buenas pruebas exploratorias también son muy valiosas: no se trata solo de hacer clic en cada enlace de la página, se trata de aprender el dominio de los usuarios finales y lo que significa para ellos usar la aplicación.

Para la proporción de QA a probadores también considere el triángulo de prueba:

    Exploratory
  Integrated Tests
Individual Unit Tests

mediante el cual una prueba exploratoria o integrada puede representar docenas, si no cientos, de pruebas unitarias ejerciendo toda la 'pila'.

También considere que, como en los equipos ágiles, generalmente debe haber un enfoque de cualquiera que pueda codificar, cualquiera pueda probar. La clave, por supuesto, es brindar a las personas la orientación y la estructura para que puedan hacer lo que sea necesario y brindarles capacitación para la otra área.

En términos de la proporción real, no estoy de acuerdo con la precisión de la respuesta de David de 3: 1 o 4: 1 En alguna organización donde los desarrolladores están escribiendo buenas pruebas unitarias e integradas, esto podría estar bien para ser 7: 1 En una organización con muy poco Las pruebas realizadas por los desarrolladores pueden ser 1: 1. Realmente "depende" de la organización, estructura, conocimiento, industria, etc.

Cuando comenzamos a construir nuestro producto , también implementamos Kanban y, junto con eso, implementamos una estrategia completa de automatización de pruebas. Como resultado, hoy no tenemos evaluadores en nuestro equipo. En cambio, los desarrolladores deben escribir casos de prueba y automatizarlos como parte del trabajo en cualquier historia de usuario, mejora o defecto. Nuestra definición de Dev Complete incluye pruebas unitarias y automatización funcional.

Todavía tenemos una etapa de "Validación" después de que se completa el desarrollo, donde todo el nuevo trabajo de desarrollo (características, correcciones de errores) se implementa en un servidor provisional y alguien, cualquiera que tenga una comprensión funcional de la característica, debe validarlo. Usamos personas de nuestro equipo de documentación, así como de gestión de productos, y a veces líderes / arquitectos de Sr. Engg, para validar. Cada versión debe permanecer un mínimo de 1 semana en la preparación antes de implementarse en producción.

Aquí hay una instantánea de nuestro tablero Kanban:

El proceso y Kanban han funcionado para nosotros. Tenemos cerca del 100% de automatización de pruebas, tenemos una cadencia de lanzamiento de producción de 3-4 semanas y, lo mejor de todo, ¡la mayoría de los miembros del equipo tienen la flexibilidad de trabajar en casi todas las partes de nuestro producto!

Por lo tanto, si bien esto puede no cumplir con sus objetivos a corto plazo, definitivamente querrá ver cómo puede reestructurar su equipo a largo plazo y, si aún no lo ha hecho, mirar estrategias de automatización de pruebas que definitivamente ayudarían a su equipo a rendir más. calidad a intervalos más cortos.