Plantilla Base de Pruebas Funcionales

Plantilla Base de Pruebas Funcionales 

 Este documento sirve como formato estándar para documentar las pruebas funcionales que cada programador debe realizar antes de enviar su desarrollo a QA. Debe completarse para cualquier tipo de tarea (roles, incidencias, métricas, validaciones, creación de doctypes, etc.). 

 1) Recursos 

 

 Enlace/s del módulo, apartado, sistema, doctype, etc. 

 Enlace/s de apk para pruebas 

 

 2) Precondiciones 

 

 Usuarios/Roles necesarios: 

 Datos iniciales cargados: 

 Estados previos del sistema: 

 Estados previos del sistema: 

 Permisos o configuraciones activas: 

 Integraciones requeridas (API, ERP, App, etc.) 

 Flujo de la tarea 

 Flujo de la tarea 

 Flujo de la tarea 

 Condiciones del flujjo 

 

 3) Casos de Prueba Funcionales 

 Regla: Para cada tarea documentar al menos 3 casos válidos y 1 caso no válido. 

 

 

 Descripción 

 

 

 Pasos 

 

 

 Datos / Condiciones 

 

 

 Resultado esperado 

 

 

 Evidencia (Screenshot) 

 

 

 Ejemplos de flujos válidos: creación de registro, consulta, modificación. Ejemplo de flujo no válido: intento con datos inválidos o permisos insuficientes. 

 4) Casos Negativos / Seguridad 

 

 

 Acceso sin permisos → debe bloquear con mensaje. 

 

 

 Datos inválidos o campos vacíos → debe mostrar validaciones. 

 

 

 Condiciones fuera de rango/tiempo → debe manejarse con error controlado. 

 

 

 5) Consideraciones (opcional) 

 6) Rutas / Funciones / Opciones Tocadas 

 

 

 Rutas frontend involucradas: 

 

 

 Endpoints backend modificados: 

 

 

 Archivos de configuración cambiados: 

 

 

 Botones, menús u opciones del sistema probadas 

 

 

 Campo: 

 

 

 

 

 

 7) Evidencias 

 Incluir capturas de pantalla de cada caso probado 8) Checklist del Programador 

 [ ] Evidencias adjuntadas [ ] Precondiciones cumplidas [ ] Casos válidos y no válidos documentados [ ] Rutas/funciones tocadas listadas / DETALLE DE PULL 

 [ ] Consideraciones (OPCIONAL) 

 9) Resultado del Peer Review 

 • Revisor: • Fecha: • Observaciones: • Decisión: Aprobado / Requiere cambios 

 10) Checklist del Code Reviewer 

 [ ] Seguridad (inputs sanitizados, queries parametrizadas, CSRF/XSS) [ ] Performance (consultas optimizadas, uso de caché) [ ] Arquitectura (respeta MVC, modularidad) [ ] Higiene del MR (commits limpios, cambios aislados) [ ] Evidencias revisadas y conformes 

   

 Ejemplo:  https://erp.overskull.com/app/task/TASK-2025-04449 

 Recursos: 

 

 

 Precondiciones: 

 

 

 Consideraciones: