🧪 MARCO METODOLOGICO DE CALIDAD (QA) EN SCRUM

📘 Control del documento

Gobierno de QA
Versión: 1.0
Documento: Marco Metodológico
Fecha: 08/07/2026

1. Objetivo

Establecer el marco metodológico oficial para la implementación del proceso de Aseguramiento de Calidad (QA) dentro del marco Scrum, garantizando:

1. Integración temprana de pruebas (Shift-Left).
2. Calidad continua del producto.
3. Trazabilidad completa del ciclo de vida.
4. Control y gestión de evidencias.
5. Mejora continúa basada en métricas.

2. Alcance

Aplica a:

1. Todos los equipos Scrum de Desarrollo de Software.
2. Proyectos nuevos, evolutivos y de mantenimiento.
3. Entregables incrementales generados por Sprint.
4. Componentes desarrollados internamente o por terceros.

Incluye:

1. Pruebas funcionales
   1. Pruebas unitarias (responsable de realizarlas desarrollo)
   2. Pruebas de integración
   3. Pruebas de sistema
   4. Pruebas UAT
   5. Pruebas de regresión
   6. Acompañamiento en la validación post-producción
2. Pruebas no funcionales cuando aplique.
3. Automatización de pruebas
4. Gestión de defectos.
5. Gestión de ambientes y datos de prueba.
6. Gestión documental asociada

---

3. Roles y Responsabilidades

a. 👤 Product Owner

1. Definir historias de usuario
2. Definir criterios de aceptación claros y verificables.
3. Priorizar el Product Backlog.
4. Aprobar historias completadas.
5. Validar incremento en Sprint Review.
6. Refinar requerimientos (Detallar funcionalidad descriptiva)
7. Aprobar casos de prueba
8. Gestión de pruebas con usuario final

b. 🧭 Scrum Master

1. Facilitar eventos Scrum.
2. Eliminar impedimentos.
3. Asegurar adherencia al marco.
4. Refinar requerimientos (participa como Modulador)
5. Promover cultura de calidad y mejora continua.

c. 👥 Scrum Team

1. Refinar requerimientos (Detallar funcionalidad descriptiva con Product Owner)
2. Realizar Matriz de Trazabilidad
3. Desarrollar funcionalidades.
4. Ejecutar pruebas unitarias.
5. Participar en revisiones de código.
6. Corregir defectos identificados.
7. Definir estrategia de pruebas del sprint.
8. Diseñar casos de prueba
9. Revisar casos de prueba (peer review)
10. Ejecutar casos de prueba.
11. Gestionar defectos e impedimentos.
12. Automatizar regresión.
13. Verificar cumplimiento de DoD.
14. Garantizar trazabilidad.
15. Generar reportes de calidad por Sprint.

---

4. Modelo de aseguramiento de la calidad

a. Principios

El proceso de QA se basa en:

1. Enfoque preventivo (Shift-Left Testing).
2. Responsabilidad compartida del Scrum Team.
3. Automatización progresiva y sostenible.
4. Evidencia objetiva y auditable.
5. Mejora continua basada en datos.

b. Tipos y Niveles de Prueba

Se establecen los siguientes tipos y niveles:

1. Pruebas Funcionales.
   1. Pruebas Unitarias (Responsable: Desarrollo).
   2. Pruebas de Integración.
   3. Pruebas de sistema (end-to-end)
   4. Pruebas UAT
   5. Pruebas de Regresión.
   6. Pruebas Post-Despliegue (smoke)
2. Pruebas No Funcionales cuando aplique:
   1. Performance.
   2. Seguridad.
   3. Compatibilidad.
   4. Usabilidad.
3. Pruebas Automatizadas

---

5. Desarrollo del procedimiento

a. Refinamiento del Backlog

📥 Entradas

1. Historias de usuario.
2. Criterios de aceptación.
3. Reglas de negocio.
4. Set de datos

🔍 Actividades QA

1. Validación de testabilidad.
2. Identificación de escenarios positivos y negativos.
3. Identificación de riesgos funcionales y técnicos.

📤 Salidas

1. Historias listas (DoR).
2. Escenarios documentados.
3. Riesgos registrados.
4. Matriz de Trazabilidad (ver formato MQA_MatrizdeTrazabilidad.xlsx)

b. Planeación del Sprint

📥 Entradas

1. Backlog priorizado.
2. Historias refinadas.

🔍 Actividades QA

1. Diseño detallado de casos.
2. Confirmar cobertura de pruebas
3. Incluir tareas QA en Sprint Backlog.
4. Acordar estrategia de automatización.
5. Actualizar Matriz de Trazabilidad con casos de prueba diseñados.

📤 Salidas

1. Sprint Backlog aprobado.
2. Plan de pruebas cargado en Azure DevOps y si no tiene Proyecto creado en Azure DevOps usar formato MQA_Plan de pruebas.docx para su revisión
3. Contar con el Test Suite y los casos de prueba creados en Azure DevOps.
4. En el caso de no contar con Proyecto creado en Azure DevOps usar formato de Matriz de casos de prueba MQA_MatrizPruebasQA.xlsx y usar este formato para la Trazabilidad.
5. Matriz de datos de prueba archivo adjuntado en el Test-Suite de Azure DevOps (ver formato MQA_MatrizDatosdePruebaQA.xlsx)
6. Plan de Mitigación cuando sea necesario y haya identificación de riesgos. Usar formato MQA_Plan de mitigación.docx

c. Ejecución del Sprint

📥 Entradas

1. Código desarrollado.
2. Build desplegado en ambiente QA.
3. Casos de prueba.
4. Datos de prueba

🔍 Actividades QA

5. Ejecución de pruebas manuales.
6. Registro y clasificación de defectos.
7. Re-test.
8. Identificación de Casos para Automatización
9. Automatización de regresión cuando ya se tengan los casos automatizados.

📤 Salidas

1. Evidencias de ejecución adjuntada al caso de prueba que se validó en Azure DevOps (ver formato MQA_EvidenciadePruebaQA.docx)
2. Registro actualizado de defectos.
3. Scripts automatizados versionados.
4. Reporte de ejecución del Sprint.
5. Matriz de Trazabilidad Actualizada con la ejecución.
6. Matriz de Automatización Backlog (ver formato MQA_MatrizAutomatizacionBacklog.xlsx)
7. Elaboración del Certificado de pruebas cuando se tenga que realizar una implementación, en conjunto con el Vo.Bo. del usuario. (ver formato MQA_Certificado de pruebas.docx)

d. Revisión del Sprint

1. Validación contra criterios de aceptación (Matriz de Trazabilidad actualizada)
2. Confirmación de cumplimiento de DoD.

Salida:

3. Incremento validado.

e. Retrospectiva

1. Análisis de tendencia de defectos.
2. Identificación de causa raíz.
3. Definición de acciones de mejora.
4. Actualización del proceso si aplica.

---

6. Modelo de pruebas automatizadas

a. Estrategia de Automatización

Se adopta el modelo de pirámide de pruebas:

• Base: Pruebas unitarias.
• Media: Pruebas de integración/API.
• Superior: Pruebas UI/E2E selectivas.

Criterios para automatizar:

1. Funcionalidades críticas del negocio.
2. Casos repetitivos.
3. Regresiones frecuentes.
4. Procesos estables.

b. Participación de QA en el Ciclo

Refinamiento:

1. Análisis de riesgos y escenarios.
2. Desarrollo: Validación temprana.
3. Build estable: Pruebas funcionales.

Cierre Sprint:

4. Regresión.
5. Post-Release: Smoke Testing.

---

7. Gestión de defectos

a. Clasificación

1. Por severidad:
   1. Crítico.
   2. Alto.
   3. Medio.
   4. Bajo.
2. Prioridad (numéricas)
   1. 1 (inmediata) 1 a 4 horas
   2. 2 (alta) 4 a 8 horas
   3. 3 (media) 1 a 2 días
   4. 4 (baja) cuando el equipo scrum decida atenderlo
3. Origen

b. Flujo de Estados

🔄 Flujo de Estados

Nuevo → En análisis → En corrección → En re-test→ Cerrado / Rechazado.

c. Criterios de Cierre

1. Corrección validada en ambiente de pruebas (QA).
2. Evidencia documentada.
3. Sin impacto colateral identificado.
4. Actualización en herramienta Azure Devops.

---

8. Trazabilidad

Debe existir relación documentada entre:

🔗 Cadena obligatoria de trazabilidad

Feature → User story→ Test case → Execution→ Defect → Liberación.

Se recomienda mantener matriz de trazabilidad actualizada por Sprint, el formato MQA_MatrizdeTrazabilidad.xlsx se actualizará por Sprint y en el caso de no tener un proyecto asignado en Azure DevOps solo usar el formato MQA_MatrizPruebasQA.xlsx, que ya incluye esta matriz en una de las hojas de este archivo.

---

9. Gestión de riesgos de calidad

Durante el refinamiento se deberán identificar:

1. Riesgos funcionales.
2. Riesgos técnicos.
3. Dependencias externas.
4. Impacto en usuario final.

⚠️ Riesgos altos

Los riesgos altos deberán contar con plan de mitigación documentado.

---

10. Gestión de ambientes y datos de prueba

Ambientes mínimos definidos

1. Desarrollo.
2. QA.
3. UAT.
4. Producción.

Cada ambiente debe contar con:

1. Control de versiones.
2. Bitácora de despliegues.
3. Responsable asignado.
4. Validar plan de rol-back UAT.

Datos de prueba

1. Anonimizados si provienen de producción.
2. Versionados y documentados.
3. Controlados para evitar inconsistencias.

---

11. Control de liberaciones

Previo a liberación

1. Cumplimiento completo de DoD.
2. Regresión ejecutada.
3. Sin defectos críticos o altos abiertos.
4. Certificado de Pruebas / Vo.Bo. QA.
5. Aprobación formal del Product Owner.
6. Verificar el plan de Rollback para producción.
7. Evidencias almacenadas en la herramienta de Azure Devops.

a. Certificado de pruebas/Vo.Bo QA

Emisión de certificado por parte de QA y autorizada por gobierno de QA (interno y proveedores). El certificado deberá contener como mínimo:

1. Nombre del proyecto.
2. Alcance funcional validado.
3. Enlaces de Azure Devops de:
   1. Plan de pruebas.
   2. Ejecución de pruebas.
   3. DashBoard QA.
4. Firma o Vo.Bo. del responsable QA.
5. Control de versiones campos siguientes
   1. Nombre del Líder QA o Tester
   2. Fecha de entrega
   3. Versión
6. Vo.Bo. del Product Owner o representante de Alpura previo a liberación productiva.

🚀 Flujo de liberación

Desarrollo → Pruebas → Re-test → Cumple DoD → Emisión Certificado QA → Aprobación PO → Liberación

---

12. Definition of ready (DoR)

Una Historia de Usuario se considera “Ready” para ser incluida en un Sprint cuando cumple con los siguientes criterios mínimos:

1. Descripción clara y entendible.
2. Criterios de aceptación definidos y verificables.
3. Reglas de negocio documentadas.
4. Dependencias identificadas.
5. Riesgos identificados.
6. Estimación realizada por el equipo.
7. Datos y ambientes necesarios identificados.
8. Cumple con el estándar de calidad documental vigente.

📋 Referencia DoR

Esto se puede validar en la Politica ALP_GBQA_PQA_02 sección 5.1 DoR

---

13. Definition of done (DoD)

Una historia se considera “Done” cuando:

1. Código implementado.
2. Code review aprobado.
3. Pruebas unitarias ejecutadas.
4. Casos de prueba ejecutados y aprobados.
5. Sin defectos críticos o altos abiertos.
6. Evidencias documentadas.
7. Automatización aplicada cuando corresponda.

---

14. Matriz RACI

• R (Responsible): Ejecuta la actividad.
• A (Accountable): Responsable final / quien aprueba.
• C (Consulted): Debe ser consultado.
• I (Informed): Debe ser informado.

Actividad	Product Owner (PO)	Scrum Master (SM)	Equipo Desarrollo (Dev)	QA
Definir criterios de aceptación	A - R	I	C	C
Refinar historias	A - R	C	R	R
Diseñar casos de prueba	I - C	I	C	R
Ejecutar pruebas unitarias	I	I	R	C
Ejecutar pruebas funcionales	I	I	C	R
Automatización de pruebas	I	I	C	R
Gestión y registro de defectos	I	I	C	R
Corrección de defectos	I	I	R	C
Validación en re-test	I	I	C	R
Aprobación de historia	A	I	C	C
Verificación de DoD	A	C	R	R
Liberación a producción	A	C	R	C
Seguimiento de métricas de calidad	I	R	C	R

---

15. Indicadores de calidad

1. Densidad de defectos.
2. Defectos escapados.
3. Cobertura automatizada.
4. Cumplimiento de DoD.
5. Tiempo medio de corrección.
6. Tendencia de defectos por Sprint.
   1. Bugs en general Vs Sprint
   2. Bugs Abiertos
   3. Bugs UAT Abiertos
   4. Bugs Productivos solo abiertos
   5. Mejoras Abiertos
   6. Riesgos identificados
   7. Bugs de Automatizacion

---

16. Definiciones

1. QA: Aseguramiento de Calidad.
2. DoD (Definition of Done): Conjunto de criterios obligatorios que determinan cuándo un incremento está completo.
3. Incremento: Producto potencialmente liberable al final del Sprint.
4. Defecto: Incumplimiento de un requisito especificado.
5. Definition of Ready (DoR): Condiciones mínimas que debe cumplir una historia para ser considerada en planificación.
6. Trazabilidad: Capacidad de relacionar requisitos, pruebas, defectos y liberaciones.

---

17. Referencias

1. Scrum Guide (versión vigente).
2. ISO 9001:2015 – Sistemas de Gestión de Calidad.
3. Política de Calidad Corporativa.
4. Procedimiento de Control de Información Documentada.
5. Estándares internos de desarrollo seguro.

---

🎉 Fin del Marco Metodológico

Este Markdown conserva el contenido del documento fuente y utiliza recursos compatibles con Docusaurus v2, incluyendo front matter, admonitions, tablas, emojis y diagramas Mermaid.