Para ser sincero, incluso una plantilla de plan de prueba que haya sido utilizada con éxito por otros equipos ágiles podría no funcionar bien para su equipo, pero ver lo que otras personas están haciendo es útil para obtener ideas sobre diferentes enfoques.
También he estado pensando en el mismo problema por un tiempo. Mi enfoque hasta ahora ha sido pragmático: estaba trabajando en un equipo pequeño y al principio era el único probador de 6 desarrolladores. Crear documentación en lugar de realizar pruebas habría sido una elección muy mala. Crear documentación en lugar de pruebas, para que los desarrolladores puedan ejecutar las pruebas: otra opción muy mala, en mi humilde opinión.
Actualmente, agregaré una página a nuestra wiki para cada historia, y que contendrá un conjunto de ideas de prueba, utilizadas como base para sesiones de prueba exploratorias. Si es necesario, también agregaré información de configuración allí. Preferiría mantener eso separado, para mantenerlo como un recurso que se pueda actualizar más fácilmente, pero en este momento va a la misma página. (Generalmente no me gusta mezclar el "cómo" y el "qué", hace que sea más difícil ver "qué" estás haciendo si tienes que elegirlo de las páginas de "cómo"). No tenemos una plantilla para esas páginas, no creo que la hayamos necesitado todavía. Cuando lo hagamos, agregaré uno y luego lo ajustaré a medida que aprendamos más. Por el momento, funciona para mí dar una visión general de las áreas que veremos cuando realicemos las pruebas y esté en la wiki,
He considerado establecer un tablero de pruebas de baja tecnología, pero por el momento, creo que nuestra pizarra es suficiente para que veamos cómo progresan las historias en este punto, aunque a medida que el equipo crezca, es posible que deseemos revisar eso.
También quería saber qué están haciendo otros probadores de Agile: aquí hay algunas publicaciones de blog que creo que le resultarán útiles:
Me gusta mucho la descripción de Marlena Compton de cómo ella usa un wiki para probar en Atlassian: http://marlenacompton.com/?p=1894
Una vez más, un enfoque liviano, que mantiene los objetivos de prueba vinculados a la historia. Ella usa un tablero de pruebas para una vista de alto nivel de las características de una versión. La característica enlaza a una página de objetivos de prueba, que se clasifican bajo diferentes encabezados: función, dominio, estrés, datos, flujo y reclamos. Esto proporciona una vista "de un vistazo" de las áreas / tipos de pruebas que ha planificado, y puede ver instantáneamente si un área tiene muchas menos pruebas. Este puede ser un enfoque que le resulte útil.
Trish Khoo también tiene algunas cosas interesantes que decir sobre el uso de una wiki, más sobre el nivel de estructuración de las pruebas individuales (se han pasado a usar un formato "dado, cuándo, luego" al estilo de Gherkin para sus pruebas):
http: / /ubertest.hogfish.net/?p=243
La publicación del blog de Elizabeth Hendrickson sobre sistemas especializados de gestión de pruebas está un poco fuera de tema, pero puede encontrar algunos puntos útiles planteados:
http://testobsessed.com/2009/10/06/specialized-test-management-systems-are-an impedimento de ágil /
lo siento, no puedo recomendar uno, pero parece que debería crear uno desde cero para su equipo según los requisitos individuales y las necesidades de prueba de su empresa.
fuente