sample template acceptance test report with examples
Resumen del informe de prueba de aceptación (Parte III):
Tutorial anterior | SIGUIENTE Tutorial
En nuestro tutorial anterior sobre ' Documentación de pruebas de aceptación con escenarios en tiempo real ”Discutimos el plan de prueba de aceptación.
En este tutorial, analizaremos en profundidad los informes del estado de la prueba de aceptación, el resumen de la prueba de aceptación y la aprobación.
Algunas plantillas genéricas se incluyen en este tutorial para mejorar su comprensión de una mejor manera. También pasaremos por encima del concepto de pruebas de aceptación en el desarrollo ágil y basado en pruebas de aceptación.
En resumen, este tutorial le explicará sobre el Informe de estado de la prueba de aceptación y el informe de resumen junto con algunas plantillas genéricas para su comprensión clara y también mejorará el concepto de prueba de aceptación en el desarrollo ágil y basado en pruebas de una manera fácilmente comprensible.
Lo que vas a aprender:
- Informe de estado de la prueba de aceptación
- Informe resumido de la prueba de aceptación
- Pruebas de aceptación en Agile
- ¿Quién realiza las pruebas de aceptación en Agile?
- Beneficios de las pruebas de aceptación en Agile
- Inconvenientes
- Desarrollo impulsado por pruebas de aceptación (ATDD)
- Conclusión
- Lectura recomendada
Informe de estado de la prueba de aceptación
El informe de prueba de aceptación siempre debe resumir las pruebas de aceptación que se realizan junto con sus resultados. Debe dirigirse a todas las partes interesadas identificadas que forman parte de la fase de prueba de aceptación. Una vez que ha comenzado la ejecución de las Pruebas de aceptación, se debe informar el progreso en el día a día.
Plantilla genérica para el informe de estado de la prueba de aceptación:
Fecha :Fecha del informe de estado de la prueba de aceptación
Detalles de ejecución de las pruebas de aceptación de hoy:
- Número de pruebas aprobadas
- Número de pruebas fallidas
- Número de pruebas en curso
Detalles de ejecución de las pruebas de aceptación hasta la fecha:
- Número total de pruebas
- Número de pruebas aprobadas
- Número de pruebas fallidas
- Número de pruebas en curso
- Número de pruebas pendientes
Detalles de defectos:
software de punto de venta para ipad
- Número de defectos registrados
- Cada defecto debe tener los siguientes detalles:
- ID, resumen, componente, gravedad
- El número total de defectos registrados hasta ahora (en fase de prueba de aceptación).
Este informe tiene que ser revisado diariamente para asegurar que la ejecución está en marcha y no hay desviaciones de los cronogramas planificados.
Informe resumido de la prueba de aceptación
Este es el informe que resume el estado de toda la fase de Prueba de aceptación. Esto implica detalles como actividades de prueba realizadas, referencias a criterios cumplidos, especificaciones de requisitos, reglas comerciales, resultados de ejecución, cronogramas planificados, desviaciones, etc.
Plantilla genérica para el informe resumido de la prueba de aceptación:
Resumen
Variaciones
Resultados
Evaluación
Recomendación
Esfuerzos
Informe de aprobación
Una vez que el Producto haya pasado las Pruebas de aceptación, se recomendará su puesta en marcha. Antes de que se lance a producción, debe estar firmado formalmente.
Plantilla genérica para informe de aprobación:
Nombre del producto, versión de lanzamiento, número de compilación
Informe más reciente
Revisado en
Revisado por
Comentarios de revisión
Fecha de cierre
Firmar por
Comentarios de cierre de sesión
En general, cualquiera de los informes anteriores debe ser revisado por las principales partes interesadas para obtener su plantilla y debe acordarse qué debe ir como información contenida.
Todos los detalles que se completan en el informe deben verificarse antes de compartirlo con las partes interesadas. Cualquier discrepancia en el informe tendrá un gran impacto en la decisión comercial y podría resultar en fallas del producto en el mercado.
Por lo tanto, los informes siempre deben ser manejados por especialistas o miembros de alto nivel del equipo.
Pruebas de aceptación en Agile
En Ágil , Los criterios de aceptación de cada historia de usuario están destinados a las pruebas de aceptación, es decir, las pruebas de aceptación se derivan de los criterios de aceptación de una historia de usuario. Cada criterio de aceptación puede tener una o más pruebas de aceptación para cubrir el escenario.
Las pruebas de aceptación generalmente son diseñadas por un QA que es el experto en la materia en el área. Las pruebas de aceptación en Agile comienzan mucho antes en comparación con los otros enfoques, generalmente dentro de los sprints.
Se realiza con mucha frecuencia, ya que cada sprint tendrá nuevas historias de usuario y también mejoras / continuación de las historias anteriores.
Las pruebas de aceptación se realizan en dos etapas diferentes en Agile:
- Cuando se crea la característica y en su etapa inicial - básica.
- Cuando la función está integrada y estabilizada con las otras funciones del producto.
Cada historia de usuario aquí debe someterse a una prueba de aceptación y debe aprobarse para su consideración. Cualquier falla en la prueba de Aceptación debe ser considerada como de alta prioridad y corregida de inmediato, esta, a su vez, tendrá la prueba de aceptación para ejecutarla.
Los puntos de historia se otorgan a cada historia de usuario en función del éxito de los resultados de la prueba de aceptación para cada uno de los criterios de aceptación. La prueba de aceptación también define la finalización a nivel de historia de usuario, indicando que se cumplen los criterios de aceptación para la historia.
¿Quién realiza las pruebas de aceptación en Agile?
Por lo general, los gerentes de producto, expertos en la materia (pueden ser clientes Y / O probadores beta) realizan pruebas de aceptación en un entorno ágil. A veces, QA también se involucra en esta actividad junto con sus tareas de regresión regulares.
Beneficios de las pruebas de aceptación en Agile
Hay varios beneficios de las pruebas de aceptación en Agile.
Los beneficios son:
- Colaboración más estrecha entre Product manager y el equipo.
- Genera confianza a nivel de historia de usuario.
- Ayudará a derivar más escenarios para cubrir cada criterio de aceptación.
- Mayor probabilidad de improvisar las soluciones al producto a través de criterios de aceptación en User Stories.
Inconvenientes
Aunque existen varios beneficios, también existen ciertos deméritos.
Los inconvenientes incluyen:
- No todas las historias se pueden considerar para las pruebas de aceptación. Solo se deben cubrir historias funcionales: es posible que se reduzca la cobertura de la historia.
- No todos los Criterios de aceptación pueden considerarse para las pruebas de aceptación. Solo se deben cubrir los criterios funcionales: la cobertura de los criterios de aceptación dentro de la historia del usuario puede disminuir.
- Dado que las partes interesadas de diferentes orígenes están involucradas y como las pruebas de aceptación de la historia se realizan directamente, es bastante difícil para todos estar en la misma página (básicamente para comprender el nivel en la historia de usuario individual).
- Dado que la duración del lanzamiento es menor en comparación con otros enfoques, es bastante difícil acomodar las pruebas de aceptación dentro de los Sprints.
Desarrollo impulsado por pruebas de aceptación (ATDD)
Esta es una de las prácticas de desarrollo ágil en la que todo el equipo discute en colaboración cada uno de los criterios de aceptación de la historia del usuario y crea pruebas de aceptación sólidas en torno a ellos.
Esto se debe a que diferentes perspectivas de cada uno de los miembros del equipo darán una nueva forma de pensar para cada uno de los criterios de aceptación y llegarán con un buen número de pruebas de aceptación cubriendo más escenarios. Algunas veces, ATDD es tambien llamado Desarrollo basado en pruebas de historia (STDD).
En realidad, ATDD ocurre antes de que comience el desarrollo. Entonces, los desarrolladores, en este enfoque, sabrán qué se espera realmente y cómo lograrlo. Todo el equipo compartirá un entendimiento común de la función y lo que se está construyendo.
Esto describe cómo se está construyendo el producto y, a su vez, dará una idea clara de cómo funcionará realmente el producto antes de entregarlo para su prueba. Por lo tanto, se denomina ' Desarrollo impulsado por pruebas de aceptación ”.
Conclusión
Las pruebas de aceptación en cualquiera de sus enfoques tienen el objetivo común de generar la confianza y satisfacción del cliente en el producto que se desarrolla antes de que entre en funcionamiento. Esto se obtiene solo cuando no hay o hay menos defectos de baja gravedad en el producto que no obstaculizan ninguna de las funcionalidades.
En una palabra:
- Se pasan las pruebas de aceptación.
- Los defectos están en niveles aceptables.
- Se logró una cobertura basada en el flujo / escenario.
- Se aceptan productos y sus soluciones.
- El cliente tiene suficiente confianza en el producto.
- Todos los documentos del producto se actualizan para adaptarse a las funciones más recientes.
- Resultado del esfuerzo del equipo.
- Es bueno seguir adelante con el lanzamiento de producción.
Tutorial anterior | SIGUIENTE Tutorial
Espero que haya obtenido un inmenso conocimiento de estos Tutoriales de prueba de aceptación. No dude en compartir sus pensamientos y plantear sus preguntas en la sección de comentarios a continuación.
Lectura recomendada
- Ejemplo de informe de errores
- Plantilla de caso de prueba de muestra con ejemplos de casos de prueba [Descargar]
- Documentos de preguntas de muestra de certificación de pruebas ISTQB con respuestas
- Cómo escribir un informe de estado semanal de pruebas de software
- Cómo escribir un informe de resumen de prueba eficaz [Descarga de informe de muestra]
- ¿Qué son las pruebas de aceptación (una guía completa)?
- Mejores herramientas de prueba de software 2021 [Herramientas de automatización de pruebas de control de calidad]
- Pruebas funcionales versus pruebas no funcionales