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: