Vista previa
Conocé el recurso antes de descargarlo
Resumen
Qué resuelve esta plantilla
Esta plantilla está pensada para planificar, ejecutar y dejar evidencia de pruebas de aceptación de usuario (UAT) y validaciones funcionales antes de liberar una funcionalidad o versión. Su estructura permite relacionar cada prueba con un requerimiento, historia de usuario o proceso de negocio, definir condiciones previas y datos de prueba, ejecutar pasos de forma repetible y registrar resultados, evidencias e incidencias. Ayuda a que negocio, QA, análisis funcional y desarrollo trabajen con criterios claros para determinar si una solución cumple lo esperado.
Público
¿Para quién está pensada?
- ✓Equipos de QA y testing que necesitan documentar pruebas funcionales y UAT de forma estructurada.
- ✓Analistas funcionales y Business Analysts que validan que una solución cumpla los requerimientos definidos.
- ✓Usuarios clave y referentes de negocio responsables de realizar pruebas de aceptación.
- ✓Product Owners y responsables de producto que necesitan evidencia antes de aprobar una funcionalidad.
- ✓Desarrolladores que requieren información reproducible para analizar resultados inesperados o defectos.
- ✓Project Managers y líderes de proyecto que necesitan conocer el estado de validación antes de una salida a producción.
Contenido
Qué incluye
- ✓Identificador, nombre, prioridad y estado del caso de prueba.
- ✓Referencia al requerimiento, historia de usuario o proceso validado.
- ✓Objetivo y alcance de la prueba.
- ✓Precondiciones necesarias antes de ejecutar el caso.
- ✓Datos de prueba y usuarios o perfiles utilizados.
- ✓Pasos de ejecución numerados y reproducibles.
- ✓Resultado esperado para cada escenario.
- ✓Resultado obtenido durante la ejecución.
- ✓Estado final: aprobado, fallido, bloqueado o pendiente.
- ✓Sección para evidencias, capturas o referencias.
- ✓Registro de incidencias o defectos detectados.
- ✓Severidad, prioridad y observaciones del defecto cuando corresponde.
- ✓Responsable y fecha de ejecución.
- ✓Resultado de re-prueba después de una corrección.
- ✓Resumen final para apoyar la decisión de aceptación.
Aplicación
Cuándo usar esta plantilla
Validar una funcionalidad nueva antes de habilitarla en producción.
Ejecutar pruebas UAT con usuarios clave o responsables de negocio.
Comprobar que una historia de usuario cumple sus criterios de aceptación.
Registrar pruebas de regresión sobre procesos críticos después de un cambio.
Documentar escenarios positivos, alternativos y de error de una funcionalidad.
Generar evidencia reproducible para informar un defecto al equipo de desarrollo.
Controlar re-pruebas luego de corregir una incidencia.
Consolidar el estado de validación de una versión antes de aprobar su liberación.
Paso a paso
Cómo utilizarla
Paso 1
Definí el objetivo de la prueba y vinculá el caso con el requerimiento, historia de usuario o proceso que se quiere validar.
Paso 2
Identificá las precondiciones, ambiente, usuario, permisos y datos necesarios antes de comenzar la ejecución.
Paso 3
Redactá pasos concretos y numerados que otra persona pueda repetir sin depender de conocimiento implícito.
Paso 4
Especificá el resultado esperado de forma objetiva para que pueda compararse con el comportamiento real.
Paso 5
Ejecutá el caso siguiendo los pasos definidos y registrá el resultado obtenido sin modificar retrospectivamente la expectativa.
Paso 6
Marcá el estado como aprobado, fallido, bloqueado o pendiente según el resultado de la ejecución.
Paso 7
Adjuntá o referenciá evidencias cuando aporten valor, especialmente en fallos o comportamientos difíciles de reproducir.
Paso 8
Si encontrás un defecto, registrá los datos necesarios para reproducirlo y vinculalo con el caso de prueba.
Paso 9
Después de una corrección, repetí el caso utilizando las mismas condiciones relevantes y registrá el resultado de la re-prueba.
Paso 10
Al finalizar el ciclo, revisá los casos pendientes o fallidos y utilizá el resumen para apoyar la decisión de aceptación o liberación.
Personalización
Cómo adaptarla a tu caso
- ✓Adaptá los estados, prioridades y severidades a la terminología utilizada por tu equipo o herramienta de gestión.
- ✓Utilizá identificadores consistentes como TC-001, UAT-001 o una convención relacionada con historias y requerimientos.
- ✓Para procesos largos, separá el flujo en varios casos pequeños para facilitar ejecución, mantenimiento y diagnóstico.
- ✓Agregá columnas para navegador, dispositivo, versión o ambiente cuando el comportamiento pueda variar según la plataforma.
- ✓Si tu equipo utiliza Jira, Azure DevOps u otra herramienta, podés mantener en la plantilla las referencias a tickets y conservarla como evidencia de aceptación.
Importante
Qué revisar antes de usarla
- ✓Un caso de prueba debe ser reproducible: otra persona debería poder ejecutarlo y obtener una conclusión comparable utilizando la misma información.
- ✓El resultado esperado debe definirse antes de la ejecución para evitar adaptar la expectativa al comportamiento observado.
- ✓Una prueba bloqueada no equivale a una prueba aprobada ni fallida; debe quedar identificado qué impide ejecutarla.
- ✓En UAT, la validación técnica no reemplaza la aceptación del negocio cuando esta forma parte del proceso definido por la organización.
Evitalos
Errores frecuentes
- ✓Escribir pasos demasiado generales que no permiten repetir la prueba de la misma manera.
- ✓No indicar los datos de prueba o el usuario utilizado cuando estos afectan el resultado.
- ✓Definir resultados esperados ambiguos como “funciona correctamente”.
- ✓Cambiar el resultado esperado después de observar el comportamiento real.
- ✓Marcar un caso como aprobado aunque no se hayan ejecutado todos los pasos relevantes.
- ✓No diferenciar un fallo funcional de un caso bloqueado por datos, ambiente o dependencias.
- ✓Reportar un defecto sin pasos de reproducción ni evidencia suficiente.
- ✓Re-probar solamente el punto corregido y omitir impactos o regresiones relevantes.
- ✓No mantener vínculo entre el caso de prueba y el requerimiento o historia que valida.
- ✓Cerrar un ciclo UAT sin revisar casos fallidos, bloqueados o pendientes.
Control final
Checklist antes de terminar
- ✓El caso tiene un identificador y un nombre claros.
- ✓Está vinculado al requerimiento, historia o proceso correspondiente.
- ✓El objetivo y alcance de la prueba están definidos.
- ✓Las precondiciones están documentadas.
- ✓Los datos de prueba necesarios están identificados.
- ✓El usuario, rol o permisos requeridos están especificados cuando corresponde.
- ✓Los pasos son concretos, numerados y reproducibles.
- ✓El resultado esperado es específico y verificable.
- ✓El ambiente o versión utilizada está registrado cuando es relevante.
- ✓El resultado obtenido quedó documentado.
- ✓El estado final coincide con el resultado de la ejecución.
- ✓Las evidencias necesarias están adjuntas o referenciadas.
- ✓Los defectos detectados están vinculados al caso de prueba.
- ✓Las re-pruebas posteriores a una corrección quedaron registradas.
- ✓Los casos bloqueados tienen documentada su causa.
- ✓Los casos pendientes o fallidos fueron revisados antes de cerrar el ciclo.
Formato
Detalles del archivo
Documento editable orientado a la planificación, ejecución y evidencia de pruebas UAT y validaciones funcionales de software. Puede utilizarse como registro por caso de prueba o adaptarse a una matriz de múltiples escenarios. La estructura permite relacionar cada prueba con requerimientos o historias, registrar pasos, datos, resultados y defectos, y conservar trazabilidad durante re-pruebas y ciclos de aceptación.
Preguntas frecuentes
Antes de descargar
¿Qué significa UAT?
UAT significa User Acceptance Testing o Pruebas de Aceptación de Usuario. Su objetivo es validar que una solución satisface las necesidades y procesos esperados por los usuarios o responsables de negocio antes de su aceptación o liberación.
¿Cuál es la diferencia entre QA y UAT?
QA puede incluir diferentes niveles y tipos de pruebas orientados a la calidad del software. UAT se concentra específicamente en validar, desde la perspectiva del usuario o negocio, que la solución permite realizar correctamente los procesos y objetivos esperados.
¿Qué debe tener un buen caso de prueba?
Debe tener un objetivo claro, precondiciones, datos necesarios, pasos reproducibles y un resultado esperado verificable. También es útil registrar el resultado obtenido, evidencia, estado y cualquier incidencia relacionada.
¿Quién debería ejecutar las pruebas UAT?
Depende del proyecto, pero normalmente participan usuarios clave, referentes de negocio, Product Owners o personas autorizadas para validar que la solución satisface la necesidad real. QA y análisis funcional pueden apoyar la preparación y ejecución.
¿Qué hago si una prueba no puede ejecutarse?
Marcala como bloqueada y documentá la causa, por ejemplo falta de datos, ambiente no disponible, dependencia pendiente o permisos insuficientes. No conviene registrarla como aprobada o fallida si realmente no pudo ejecutarse.
¿Cómo debería registrar un defecto encontrado durante UAT?
Registrá los pasos para reproducirlo, resultado esperado, resultado obtenido, datos utilizados, ambiente, evidencia y severidad o impacto cuando corresponda. También vinculá la incidencia con el caso de prueba y requerimiento relacionados.
¿Es necesario volver a ejecutar una prueba después de corregir un defecto?
Sí, cuando el defecto afectaba ese caso. La re-prueba permite confirmar que la corrección resolvió el problema. Según el impacto del cambio, también puede ser necesario ejecutar pruebas de regresión relacionadas.
¿Puedo usar esta plantilla para pruebas de regresión además de UAT?
Sí. La estructura de caso, pasos, datos, resultados y evidencias también puede utilizarse para pruebas funcionales y de regresión, adaptando los campos a las necesidades del equipo.
Transparencia editorial
Recurso preparado y revisado por SG Hub
Esta ficha busca explicar no solo qué descargar, sino también cuándo utilizar el recurso y qué revisar antes de aplicarlo en una situación real.