Ir al contenido principal

CLASIFICACIÓN DE CASOS DE PRUEBA







                                          CLASIFICACIÓN DE CASOS DE PRUEBA

25/02/2026

Versión 0.1












Queda prohibido cualquier tipo de explotación y, en particular, la reproducción, distribución, comunicación pública y/o transformación, total o parcial, por cualquier medio, de este documento sin el previo consentimiento expreso y por escrito a overskull.


ÍNDICE DE CONTENIDOS
1. OBJETIVO
  • Propósito de la estandarización y metas de calidad.
2. ALCANCE
  • Tipos de proyectos y obligatoriedad de la política.
3. CLASIFICACIÓN DE CASOS DE PRUEBA
  • 3.1 Casos de Prueba Positivos (Happy Path).
  • 3.2 Casos de Prueba Negativos (Validaciones).
  • 3.3 Casos de Borde (Boundary Testing).
  • 3.4 Casos de Integración (APIs y Sistemas).
  • 3.5 Casos de Seguridad (Accesos y Roles).
  • 3.6 Casos de Regresión (Estabilidad).
  • 3.7 Casos End to End (E2E).
  • 3.8 Casos de Performance (Carga y Estrés).
4. FLUJO DE PROCESO Y CICLO DE VIDA (QA)
  • Diagrama Visual del Flujo (Mermaid).
  • Descripción detallada de etapas (Análisis, Diseño, Revisión, Ejecución y Cierre).
5. LINEAMIENTOS GENERALES
  • 5.1 Cobertura Mínima Obligatoria (El Estándar 4/4).
  • 5.2 Estructura Obligatoria del Caso de Prueba (Campos requeridos).
6. IMPORTANCIA ESTRATÉGICA
  • Beneficios para el área y reducción de riesgos operativos.
7. DISPOSICIÓN FINAL
  • Marco de cumplimiento y vigencia institucional.


1. OBJETIVO

Establecer un estándar formal para la clasificación de los casos de prueba utilizados por el Área de Aseguramiento de la Calidad (QA), con la finalidad de garantizar cobertura funcional, técnica y no funcional en todos los requerimientos desarrollados, asegurando consistencia metodológica, reducción de riesgos y mejora continua del proceso de pruebas.

2. ALCANCE

El presente estándar es de cumplimiento obligatorio para todos los proyectos gestionados por el área de QA, incluyendo:

  • Nuevos desarrollos.

  • Mejoras evolutivas y correctivas (Bugs).

  • Integraciones con sistemas internos o terceros.

  • Cambios regulatorios o normativos.

  • Proyectos críticos para el negocio.

3. CLASIFICACIÓN DE CASOS DE PRUEBA

Categoría Definición Objetivo Principal
3.1 Positivos Validan el flujo esperado con datos válidos. Confirmar el "Happy Path" del negocio.
3.2 Negativos Evalúan el sistema ante datos inválidos o acciones no permitidas. Garantizar gestión de errores y restricciones.
3.3 Casos de Borde Evalúan valores mínimos, máximos y límites críticos. Detectar fallos en rangos numéricos o de formato.
3.4 Integración Validan interacción entre módulos, APIs y bases de datos. Asegurar integridad en el intercambio de datos.
3.5 Seguridad Evalúan autenticación, roles y protección de datos. Prevenir vulnerabilidades y accesos no autorizados.
3.6 Regresión Verifican que lo existente no se haya dañado con cambios nuevos. Mantener la estabilidad acumulativa del sistema.
3.7 End to End (E2E) Validan el flujo completo desde el inicio al resultado final. Simular el comportamiento real del usuario integral.
3.8 Performance Evalúan el comportamiento bajo carga, volumen o estrés. Medir tiempos de respuesta y estabilidad.

4. FLUJO DEL PROCESO DE QA (CICLO DE VIDA)

Para asegurar la aplicación de esta política, se define el siguiente flujo operativo:

  1. Análisis: Identificación de tipos de prueba necesarios según el requerimiento.

  2. Diseño: Redacción de casos siguiendo la estructura del punto 5.2.

  3. Revisión: Validación del plan de pruebas por el QA Lead (Peer Review).

  4. Ejecución: Corrida de pruebas, registro de evidencias y reporte de defectos.

  5. Cierre: Firma de aceptación (Sign-off) basada en cobertura lograda.

Diagrama de flujo:

image.png

5. LINEAMIENTOS GENERALES

5.1 Cobertura Mínima Obligatoria

Todo requerimiento deberá incluir sin excepción:

  1. Casos Positivos

  2. Casos Negativos

  3. Casos de Borde

  4. Casos de Regresión

Nota: Los casos de Integración, Seguridad, Performance y E2E se incorporarán según la criticidad del proyecto.

5.2 Estructura Obligatoria del Caso de Prueba

Cada caso de prueba debe estar documentado con los siguientes campos:

  • ID único: Identificador alfanumérico.

  • Tipo de caso: (Según sección 3).

  • Requerimiento: ID de la historia de usuario o tarea.

  • Prioridad: (Alta / Media / Baja).

  • Precondiciones: Estado necesario previo a la ejecución.

  • Datos de prueba: Valores específicos a utilizar.

  • Pasos de ejecución: Secuencia lógica y clara.

  • Resultado esperado: Comportamiento correcto definido.

  • Resultado obtenido: Lo que sucedió realmente.

  • Evidencia: Capturas de pantalla, logs o videos.

  • Estado: (Aprobado / Fallido / Bloqueado).

6. IMPORTANCIA ESTRATÉGICA

La aplicación de este estándar permite:

  • Reducir riesgos operativos y financieros.

  • Facilitar auditorías internas y externas.

  • Estandarizar el entregable del equipo de QA.

  • Asegurar la trazabilidad total del software.

7. DISPOSICIÓN FINAL

El presente documento constituye el estándar oficial del Área de QA. Su omisión será considerada una falta al proceso de aseguramiento de calidad institucional.

8. DOCUMENTO REALIZADO

En el present documento se muestra el proceso realizado cada dia para poder realizar los casos a las tareas para que luego se ejecuten cada uno de los casos   https://docs.google.com/spreadsheets/d/1cGA4k7SN0XBhPUza_UttD1Zla2iQK2dKSe8nrPyqdP4/edit?ouid=108889832804466309506&usp=sheets_home&ths=true  


No hay comentarios para mostrar

Volver arriba