Plan de prueba ágil: ¿realmente necesitamos uno?

¿Necesitamos un documento de plan de prueba ágil?

La planificación de pruebas es una actividad importante de un proceso de pruebas y requiere pensamientos y decisiones cuidadosos no solo del gerente de pruebas (que generalmente es responsable de crear el plan de pruebas), sino de todos los miembros del equipo de pruebas y del gerente de desarrollo de productos.

Algunas personas creen que es la parte más importante del proceso de prueba (personalmente creo que el diseño de pruebas y el pensamiento abstracto son los más importantes) y dedican muchas horas y esfuerzo a crear un gran plan de prueba.

Los libros de texto dedican una sección completa relacionada con la planificación de pruebas, cómo escribir una y qué incluir en un plan de prueba, mientras que algunos órganos rectores y organizaciones reguladoras como la FDA requieren un plan de prueba integral para aprobar un producto.

En el mundo real, en un entorno en cascada, a menudo el documento del plan de prueba es uno que casi nunca se examina durante el ciclo de vida del producto. La actividad de “Planificación y Monitoreo de Pruebas” debe ser una actividad continua durante el ciclo de vida del proyecto, debe actualizarse según los cambios del proyecto, pero en la mayoría de los casos este no es el caso; El plan de prueba no está actualizado o los cambios son retrospectivos, lo que hace que el documento del plan de prueba sea el subproducto menos valioso.

Si bien la planificación de pruebas casi siempre se considera un producto imprescindible en un proyecto en cascada, ¿realmente necesitamos un plan de prueba para un proyecto ágil? es decir, ¿realmente agrega algún valor a lo que todo el equipo está tratando de lograr?

El manifiesto ágil favorece claramente software de trabajo sobre documentación completa y respondiendo al cambio sobre seguir un plan.

En un entorno ágil, el contenido de una versión (los elementos) se discute antes del sprint para que el equipo de pruebas sepa de antemano cuál es el alcance y qué se debe probar.

En el 'juego de planificación de póquer', las estimaciones se analizan para que el equipo de pruebas sepa cuánto tiempo llevará probar una función (esto incluye la configuración del entorno, los escenarios, la automatización, la exploración, el rendimiento, etc.).

En la “sesión de escritura de historias”, donde se analizan los detalles de cada característica, el equipo de prueba ya está comenzando a escribir escenarios para cubrir las muchas formas en que se pueden probar las historias; esta es la actividad más valiosa del equipo.

Durante el sprint, QA está probando continuamente nuevos códigos / funciones. La planificación de pruebas se convierte en una actividad dinámica a medida que cambian las prioridades del día. Las pruebas se basan en cuál es la actividad del día y el resultado del día anterior.

Es claramente evidente que el plan de prueba no revela defectos, pero los escenarios de prueba sí. El esfuerzo debe centrarse en la creación de mejores escenarios que en la creación de un plan de prueba.

Lo que realmente se necesita es un breve Documento de estrategia de prueba ágil que describe los procesos aplicables en los sprints. , es decir, secciones sobre planificación de sprint, talleres de especificaciones, control de calidad manual, automatización, cobertura de prueba, informes de prueba, entornos de prueba, puesta en escena, etc. Estos son procesos y actividades aplicables a cada sprint pero, por supuesto, derivados de la visión de la empresa.

Entonces, con todo esto en mente, ¿el documento del plan de prueba o las estrategias de prueba extensas son realmente cosa del pasado? ¿Realmente necesitamos un plan de prueba ágil?