La ejecución de las pruebas UAT, a diferencia de las pruebas de desarrollo, no tienen como objetivo reportar
defectos. Se espera que los usuarios que participan en las pruebas reporten la aceptación o no de la solución
entregada. No obstante, se debe considerar la posibilidad de que surjan defectos en el proceso. Para estos
casos, es necesario generar un registro de incidente (potencial defecto) en el cual se detalle:
-
Requerimiento de negocio o funcionalidad al cual está relacionado
-
Criticidad del defecto
-
Prioridad del defecto
-
Impacto potencial del defecto
-
Tipo de defecto
-
Descripción del defecto
-
Resultado esperado y evidencia del resutado obtenido
-
Pasos para reproducir el defecto y datos necesarios para su reproducción
-
Trazabilidad al caso de prueba ejecutado
En la descripción debe especificarse cuál es el problema en términos del requerimiento, con esto, se tendrá una mejor
comprensión y podrá darse una pronta y acertada solución al defecto.
Una buena práctica es centralizar los defectos, analizarlos y clasificarlos antes de derivarlos al área de tecnología.
Así se evitan enviar como defectos: dudas, preguntas, aspectos que no fueron solicitados en los requerimientos, errores
duplicados, entre otros. Al igual que las pruebas que realiza el equipo de desarrollo, es recomendable es que este
reporte de incidentes (bugs) sea realizado a través de una herramienta tecnológica de seguimiento o tracking de
incidencias, que permita reportar las incidencias con un identificador único y permita relacionar el reporte de defecto
a la versión del software que se está probando, el caso de prueba que se está ejecuctando y proyecto en el cual se está
trabajando. Algunas opciones gratuitas pueden ser: Bugzilla, Mantis, Request Tracker (RT), o similares.
|
