# 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:
- ![](https://shalom-documentation.shalomcontrol.com/uploads/images/gallery/2025-11/embedded-image-atiutob1.png)

##### 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](https://erp.overskull.com/app/task/TASK-2025-04449)

Recursos:

![](https://shalom-documentation.shalomcontrol.com/uploads/images/gallery/2025-11/embedded-image-hk4vtg18.png)

Precondiciones:

![](https://shalom-documentation.shalomcontrol.com/uploads/images/gallery/2025-11/embedded-image-1cz4fckn.png)

Consideraciones:

![](https://shalom-documentation.shalomcontrol.com/uploads/images/gallery/2025-11/embedded-image-i67s2ibx.png)