PROCESO DE ASEGURAMIENTO DE CALIDAD
- Versión: 1.0
- Tipo: Política Corporativa
- Fecha: 08/07/2026
Objetivo
Establecer el marco metodológico oficial para la implementación del proceso de Aseguramiento de Calidad (QA) dentro del marco Scrum, garantizando:
- Integración temprana de pruebas (Shift-Left).
- Calidad continua del producto.
- Trazabilidad completa del ciclo de vida.
- Control y gestión de evidencias.
- Mejora continua basada en métricas.
Alcance
Aplica a:
- Todos los equipos Scrum de Desarrollo de Software.
- Proyectos nuevos, evolutivos y de mantenimiento.
- Entregables incrementales generados por Sprint.
- Componentes desarrollados internamente o por terceros.
Incluye:
- Pruebas unitarias (Responsable de desarrollo)
- Pruebas funcionales
- Pruebas de integración
- Pruebas de regresión
- Pruebas UAT
- Acompañamiento en la validación post-producción
- Automatización de pruebas
- Pruebas no funcionales cuando aplique.
- Gestión de defectos.
- Gestión de ambientes y datos de prueba.
- Gestión documental asociada
Principios de Calidad
Un principio de calidad es una directriz fundamental que orienta la forma en que una organización planifica, desarrolla, ejecuta y mejora sus procesos y productos, con el objetivo de asegurar que estos cumplan consistentemente con los requisitos establecidos y las expectativas del cliente.
Los principios de calidad permiten garantizar que los productos no solo funcionen correctamente, sino que sean confiables, seguros, mantenibles y alineados con los objetivos del negocio. La compañía adopta los siguientes principios:
Modelo de Principios de Calidad (Pilares Fundamentales)
El siguiente diagrama ilustra cómo los 6 Principios de Calidad actúan como pilares que soportan todo el ciclo de desarrollo, desde la concepción del requerimiento hasta la entrega de valor al cliente, y retroalimentan el sistema mediante la mejora continua:
- Origen del Valor: Todo nace de los requisitos y expectativas del cliente (arriba).
- 6 Pilares (columna central morada): Sostienen todo el proceso — no son una etapa, sino la base sobre la cual se ejecuta cada fase.
- Ciclo de Desarrollo (centro, horizontal): Cada etapa (DoR → Dev → Pruebas → Liberación → Operación) se ejecuta sobre los 6 pilares.
- Mejora Continua (loop): La operación realimenta el P6, optimizando las siguientes iteraciones.
- Resultados (abajo): Producto estable, valor real, cumplimiento y entregas frecuentes.
Resumen Ejecutivo (Quick Reference)
| # | Principio | Aplicación Diaria | Métrica Clave |
|---|---|---|---|
| 1 | Shift Left | QA presente en refinamientos y DoR | Defectos detectados antes de QA |
| 2 | Responsabilidad Compartida | Unit tests + PR checklist obligatorios | % Defectos de desarrollo vs QA |
| 3 | Prevención | Checklist de diseño, análisis de riesgos | Coste retrabajo / Coste total |
| 4 | Automatización | Pirámide de pruebas (unit > integración > e2e) | % Cobertura automatizada crítica |
| 5 | Trazabilidad Total | Links en Azure DevOps: Req → Dev → Test | % Requisitos con evidencia |
| 6 | Mejora Continua | Retrospectiva QA + métricas por sprint | Tendencia de Defect Density |
1. Calidad desde el inicio (Shift Left)
El principio de “Calidad desde el inicio” (Shift Left) se refiere a la práctica de incorporar actividades de aseguramiento y control de calidad en las etapas más tempranas del ciclo de vida del desarrollo de software, en lugar de concentrarlas únicamente en fases finales como pruebas o validación previa a producción.
Se trasladan actividades de testing hacia fases como el análisis de requisitos, diseño funcional y técnico, refinamiento de historias de usuario y definición de criterios de aceptación. El objetivo es prevenir defectos en lugar de detectarlos tardíamente, cuando su corrección resulta más costosa y compleja (hasta 6 veces más caro según IBM).
“La calidad se construye desde la definición de requisitos, no solo al final del desarrollo.”
Este enfoque reduce retrabajo, mejora la cobertura de riesgos, incrementa la eficiencia del equipo y acelera la entrega de valor. Además, fortalece la colaboración entre desarrollo, QA y negocio, promoviendo la calidad como responsabilidad compartida.
- Refinamiento: El QA participa en el refinement para redactar Criterios de Aceptación (Given/When/Then) verificables.
- Definition of Ready (DoR): Una historia no entra al sprint si no tiene criterios probables, criterios de aceptación y dependencias claras.
- Diseño Técnico: QA revisa el diseño técnico para identificar puntos de riesgo (integraciones, edge cases, performance).
- Pruebas Estáticas: Linting, SAST, análisis de complejidad y revisiones de PARES antes de mergear.
“QA recibe el sprint ya cerrado y tiene 1 día para probar todo.” “Criterios de aceptación escritos después del desarrollo.” “Refinamiento sin QA presente.”
- > 60% de los defectos detectados antes de la fase de testing.
- Reducción del 30% del tiempo dedicado a corrección de bugs tardíos.
- Criterios de aceptación 100% definidos antes del inicio del sprint.
“Calidad desde el inicio” no es solo adelantar pruebas, sino integrar la mentalidad de calidad desde la concepción del producto, asegurando que cada decisión temprana contribuya a construir software robusto, mantenible y alineado con las expectativas del usuario.
2. Responsabilidad compartida
El principio de calidad “Responsabilidad compartida” establece que la calidad no es una función exclusiva del área de QA o Testing, sino un compromiso colectivo que involucra a todos los roles del equipo: negocio, análisis, desarrollo, arquitectura, operaciones y aseguramiento de calidad.
Este principio implica que cada integrante del equipo es responsable de prevenir defectos, cumplir estándares y garantizar que el producto entregue valor real al usuario final. El tester no es el “dueño de la calidad”, sino un facilitador, impulsor y referente técnico que promueve buenas prácticas y pensamiento crítico orientado al riesgo.
“La calidad es responsabilidad de todo el equipo (Product Owner, Scrum Master, Scrum Team)”.
- Desarrolladores: Escriben tests unitarios (mínimo 70% cobertura en código crítico) y ejecutan smoke tests locales antes del Pull Request.
- Product Owner: Asegura que los criterios de aceptación sean verifiCABLES y prioriza la deuda técnica junto a nuevas features.
- Arquitectos: Definen estándares (seguridad, performance, mantenibilidad) y validan su cumplimiento en revisiones.
- SRE / Operaciones: Pruebas de resiliencia, observabilidad y monitoreo productivo con alertamiento temprano.
“Dev tira el código por la ventana; QA se encarga de agarrar los bugs.” “Si QA no lo encontró, no es mi responsabilidad.” “Pull Requests aprobados sin revisión, solo merge.”
- > 70% de defectos detectados por desarrolladores (unit + integration) antes de llegar a QA.
- Métrica “Bugs QA encontrados / Bugs Dev encontrados” con tendencia a la baja.
- 100% de PRs con checklist de calidad firmado por el autor.
Este principio establece que la calidad no se inspecciona al final del proceso, sino que se construye de manera colaborativa en cada etapa del ciclo de desarrollo, siendo un compromiso integral del equipo y no una función aislada.
3. Prevención sobre corrección
El principio de calidad “Prevención sobre corrección” establece que es más eficiente, económico y estratégico evitar la introducción de defectos que detectarlos y corregirlos en etapas posteriores del ciclo de vida del software.
Este principio implica adoptar un enfoque proactivo orientado a la identificación temprana de riesgos, ambigüedades y posibles fallos antes de que se materialicen en errores funcionales o incidentes en producción. La corrección tardía no solo incrementa costos, sino que impacta tiempos de entrega, reputación y experiencia del usuario.
“Se prioriza prevenir defectos antes que detectarlos en producción.”
La prevención reduce retrabajo, mejora la estabilidad del producto y optimiza el esfuerzo del equipo. Además, fortalece una cultura de calidad madura, donde el enfoque no es “detectar errores”, sino “evitar que ocurran”.
- Checklist de Riesgos: Al inicio de cada sprint, se identifican los 3 riesgos funcionales/técnicos más probables y se diseñan pruebas específicas para ellos.
- Reuniones Kickoff Feature: Antes de empezar una feature grande, todo el equipo (PO, Dev, QA) define expectativas, edge cases y dependencias.
- Análisis de Causa Raíz (RCA): Cada bug productivo genera una acción correctiva que previene que la misma clase de fallo se repita (ej: si falló un límite numérico, se agrega a la suite un test parametrizado de boundary testing).
“Bug detectado → arreglado → problema cerrado. No preguntamos POR QUÉ pasó.” “Siempre hay tiempo para corregirlo después, pero no para diseñarlo bien ahora.”
- Tasa de recurrencia de bugs (misma causa raíz) < 2%.
- > 80% de acciones de RCA implementadas en 2 sprints.
- Densidad de defectos por sprint con tendencia decreciente.
“Prevención sobre corrección” promueve una mentalidad anticipativa y estratégica, donde la calidad se construye desde el diseño y la planificación, minimizando impactos operativos y asegurando entregas más confiables y sostenibles.
4. Automatización estratégica
El principio de calidad “Automatización Estratégica” se refiere a la implementación planificada y orientada al valor de la automatización de pruebas y procesos, con el objetivo de maximizar la eficiencia, reducir riesgos y asegurar la calidad de manera sostenible.
Este principio implica que la automatización no debe ejecutarse de forma indiscriminada ni por tendencia tecnológica, sino basada en criterios técnicos y de negocio claros. Automatizar estratégicamente significa priorizar escenarios críticos, repetitivos, de alto riesgo o alto volumen, garantizando un retorno de inversión tangible.
“Se promueve la automatización progresiva de pruebas críticas y regresivas.”
La automatización estratégica contribuye a ciclos de entrega más cortos, detección temprana de defectos, reducción de errores humanos y mayor estabilidad en entornos productivos. No reemplaza el pensamiento crítico del tester, sino que lo potencia, permitiéndole enfocarse en pruebas exploratorias, análisis de riesgos y validaciones de alto valor.
- Unitarios: Desarrollador; corrida en pre-merge.
- Integración / API: QA + Dev; corrida en cada commit (CI).
- E2E: QA; corrida nocturna + pre-release.
- Seguridad / Performance: Gating obligatorio en CI antes de pasar a UAT.
“Automatizamos TODO el 100% de casos sin priorizar.” “Suite de E2E gigante que tarda 4 horas y nadie confía en ella (tests frágiles).” “Cambio de UI → se rompen 50 tests y nadie lo mantiene.”
- Cobertura de casos CRÍTICOS automatizados → 100%.
- Flakiness rate (tests inestables) < 2%.
- Tiempo de corrida de regresión automatizada < 1 hora.
Este principio establece que la automatización debe ser una decisión consciente y alineada con la estrategia de calidad, priorizando impacto, sostenibilidad y aporte real al negocio.
5. Trazabilidad total
El principio de calidad “Trazabilidad total” se refiere a la capacidad de rastrear de manera clara, estructurada y verificable cada requisito desde su origen hasta su validación final, incluyendo su diseño, desarrollo, pruebas y liberación a producción.
La trazabilidad total garantiza que cada requerimiento tenga evidencia de implementación y validación, y que cada defecto pueda vincularse a su causa raíz. Este principio fortalece el control, la transparencia y la gobernanza del proceso de desarrollo.
“Toda funcionalidad debe tener trazabilidad en Azure DevOps desde el requerimiento hasta la validación.”
Este enfoque permite identificar rápidamente impactos ante cambios, medir cobertura de pruebas, cumplir con auditorías y normativas, y reducir riesgos asociados a funcionalidades no validadas.
Regla obligatoria: Ningún PBI pasa a “Done” si no tiene:
- Link al caso de prueba ejecutado.
- Evidencia (screenshot, video, logs).
- Si es bug, link al RCA y acción correctiva.
“Probaremos lo que podamos y anotaremos después.” “Bugs en Excel o Slack, sin Work Item.” “Liberamos a producción sin saber QUÉ PBIs exactos van incluidos.”
- 100% de los Work Items aprobados tienen Casos de Prueba asociados.
- 100% de los Bugs productivos tienen Work Item + RCA documentada.
- Auditorías externas pasan con observaciones 0 en trazabilidad.
Este principio establece que la calidad debe ser completamente rastreable, medible y demostrable, garantizando que ningún requerimiento quede sin implementar ni validar, y que todo el ciclo de vida del software sea transparente y controlado.
6. Mejora continua
El principio de calidad “Mejora continua” se refiere al compromiso permanente de evaluar, optimizar y perfeccionar procesos, prácticas y resultados con el objetivo de incrementar la eficiencia, reducir defectos y elevar el nivel de madurez organizacional.
La mejora continua no se limita a corregir errores identificados, sino que implica analizar sistemáticamente el desempeño del proceso de pruebas y desarrollo para identificar oportunidades de optimización sostenida. Se basa en datos, métricas y aprendizaje continuo (ciclo PDCA: Planificar → Hacer → Verificar → Actuar).
“La calidad será medida y optimizada continuamente mediante métricas objetivas.”
La mejora continua fortalece la capacidad de adaptación ante cambios tecnológicos y de negocio, incrementa la eficiencia operativa y eleva la confiabilidad del producto. Además, fomenta una cultura donde el aprendizaje y la autocrítica constructiva son parte integral del trabajo diario.
- Retrospectiva QA: Cada 2 sprints se revisan las 8 métricas de la sección siguiente (Densidad, Escape Rate, TMR, Cobertura, etc.).
- RCA de cada incidente productivo → genera al menos una mejora prevEntiva.
- Capacitación continua: Certificaciones ISTQB, talleres internos de testing, benchmark con otras unidades.
“Hacemos retros, anotamos action items y nunca los volvemos a ver.” “Medimos métricas pero no tomamos decisiones con ellas.” “Siempre hacemos lo mismo porque siempre lo hicimos así.”
- Madurez TMMi (Test Maturity Model): progresar de Nivel 2 → Nivel 3 → Nivel 4 en 18 meses.
- Índice de satisfacción del equipo QA / Dev con el proceso → creciente trimestral.
- 90%+ de action items de retrospectiva cerrados en plazo.
Este principio establece que la calidad no es un estado estático, sino un proceso evolutivo que requiere evaluación constante, toma de decisiones basada en evidencia y compromiso organizacional para alcanzar niveles superiores de desempeño y excelencia.
Métricas establecidas en Azure DevOps (recomendadas):
- Bugs en general Vs Sprint
- Bugs Abiertos
- Bugs UAT Abiertos
- Bugs Productivos solo abiertos
- Mejoras Abiertos
- Riesgos identificados
- Bugs de Automatizacion
Estándares Obligatorios
Definition of Ready
Una Historia de Usuario se considera “Ready” para ser incluida en un Sprint cuando cumple con los siguientes criterios mínimos:
- Descripción clara y entendible
- Criterios de aceptación definidos: establece que toda historia de usuario o ítem del backlog debe contar con condiciones claras, completas y verificables que determinen cuándo se considerará correctamente implementado, es decir:
- Los criterios estén redactados de forma específica, sin ambigüedades ni interpretaciones abiertas.
- Sean medibles y comprobables, permitiendo diseñar casos de prueba objetivos.
- Cubran escenarios positivos, negativos y alternativos, incluyendo validaciones, reglas de negocio y restricciones.
- Incluyan, cuando corresponda, consideraciones no funcionales (rendimiento, seguridad, usabilidad, accesibilidad, etc.).
- Sean consistentes con los requisitos funcionales y el alcance definido.
- Permitan determinar de manera inequívoca el estado de “cumple” o “no cumple”.
Un ítem no debería considerarse “Ready” si los criterios:
- Son demasiado generales (“El sistema debe funcionar correctamente”).
- No especifican resultados esperados.
- No definen reglas de negocio clave.
Definition of Done Corporativa
Ninguna historia podrá pasar a “Done” si no cumple:
- Criterios de aceptación definidos: establece que toda historia de usuario o ítem del backlog debe contar con condiciones claras, completas y verificables que determinen cuándo se considerará correctamente implementado.
- Casos de prueba diseñados y ejecutados.
- Evidencia registrada.
- Sin defectos críticos o altos abiertos.
- Pruebas regresivas impactadas ejecutadas.
Gestión de Defectos
- Todo defecto debe registrarse en Azure DevOps.
- Clasificación obligatoria por severidad y prioridad.
- Defectos críticos deben resolverse antes del cierre del sprint.
- Se realizará análisis de causa raíz en defectos productivos críticos.
Tipos de Pruebas Requeridas
Dependiendo del tipo de desarrollo:
Pruebas funcionales
Son aquellas que verifican que el sistema cumpla con los requisitos funcionales definidos, es decir, que haga exactamente lo que debe hacer según las especificaciones, historias de usuario o criterios de aceptación.
-
Las pruebas funcionales validan:
- ✅ Reglas de negocio
- ✅ Flujos de usuario
- ✅ Entradas y salidas de datos
- ✅ Integraciones entre módulos
- ✅ Mensajes de error y validaciones
- ✅ Permisos y roles
- ✅ Cálculos y lógica del sistema
-
Dentro de las pruebas funcionales encontramos:
- Pruebas unitarias: Validan componentes individuales (normalmente realizadas por desarrolladores).
- Pruebas de integración: Verifican que distintos módulos funcionen correctamente juntos.
- Pruebas de sistema (end-to-end): Evalúan el sistema completo en un entorno similar a producción.
- Pruebas de aceptación (UAT): Validan que el sistema cumple con las expectativas del cliente o usuario final.
- Pruebas de regresión: Aseguran que cambios recientes no afecten funcionalidades existentes.
- Pruebas de APIs (cuando aplique).
Pruebas No funcionales
Son aquellas que evalúan cómo funciona el sistema, no qué hace. Se enfocan en atributos de calidad como rendimiento, seguridad, usabilidad y estabilidad.
- Las pruebas No funcionales validan aspectos como:
- 🚀 Rendimiento: Evalúan cómo responde el sistema bajo determinadas condiciones. Incluyen:
- Pruebas de carga: comportamiento con usuarios esperados.
- Pruebas de estrés: comportamiento bajo condiciones extremas.
- Pruebas de volumen: manejo de grandes cantidades de datos.
- Pruebas de picos (spike): aumentos repentinos de usuarios.
- Pruebas de resistencia (soak): funcionamiento prolongado en el tiempo.
- 🔐 Seguridad: Validan la protección de datos y accesos indebidos. Incluyen:
- Pruebas de autenticación y autorización
- Validación contra SQL Injection
- XSS
- Fuerza bruta
- Gestión de sesiones
- Encriptación de datos
- 🎯 Usabilidad: Evalúan qué tan fácil es usar el sistema. Se revisa:
- Claridad de interfaz
- Flujo intuitivo
- Accesibilidad
- Tiempo de aprendizaje
- 🌐 Compatibilidad: Validan funcionamiento en distintos:
- Navegadores
- Sistemas operativos
- Dispositivos
- Versiones
- 🔄 Recuperación ante fallos
- 📈 Escalabilidad
- 💾 Estabilidad
- 🚀 Rendimiento: Evalúan cómo responde el sistema bajo determinadas condiciones. Incluyen:
Marco de Gobierno de QA
Estandarización de Procesos
Todos los equipos Scrum deberán:
- Aplicar una Definition of Ready (DoR) y Definition of Done (DoD) estandarizada.
- Incorporar criterios de aceptación claros y verificables en cada User Story.
- Registrar y gestionar pruebas y defectos en Azure DevOps.
- Cumplir con los Quality Gates definidos antes de promover entregas a producción.
Gestión de Pruebas
- Cada User Story debe contar con evidencia de validación funcional.
- Se deberán ejecutar pruebas en los niveles correspondientes: unitarias, integración, sistema y regresión.
- Las pruebas críticas y repetitivas deberán ser automatizadas progresivamente.
- Las evidencias de ejecución deberán mantenerse en Azure DevOps dentro de la ejecución de los casos de prueba o herramienta integrada.
- Al implementar una o más User Story se deberá entregar a Gobierno de QA, un certificado de pruebas para su Vo.Bo. De implementación
Integración con CI/CD (DevOps)
El pipeline deberá incluir como mínimo:
- Ejecución automática de pruebas unitarias.
- Validación de cobertura mínima de código.
- Análisis estático de calidad.
- Ejecución de pruebas automatizadas de regresión.
- Validaciones de seguridad cuando aplique.
- Ningún despliegue a entornos productivos podrá realizarse sin cumplir los Quality Gates (Estándares Obligatorios) definidos.
Trazabilidad y Gestión en Azure DevOps
- Toda funcionalidad debe originarse en un Work Item (Epic/Feature/User Story).
- Cada User Story debe vincularse a casos de prueba.
- Los defectos deben estar asociados al requerimiento afectado.
- Debe mantenerse una matriz de trazabilidad verificable en la herramienta.
La información registrada en Azure DevOps constituye la fuente oficial de control y auditoría.
La trazabilidad de los requerimientos sirve para poder rastrear y controlar cada requisito a lo largo de todo el ciclo de vida del proyecto: desde su origen hasta su implementación, prueba y entrega.
¿Para qué sirve la trazabilidad?
- Asegurar cobertura completa: Permite verificar que todos los requisitos tienen al menos un caso de prueba asociado. 👉 Evita que algo quede sin validar.
- Detectar huecos y redundancias: Identifica requisitos sin pruebas o pruebas que no están asociadas a ningún requisito.
- Gestionar cambios: Cuando un requisito cambia, puedes identificar rápidamente:
- Qué casos de prueba impacta
- Qué funcionalidades se ven afectadas
- Qué defectos pueden estar relacionados
- Mejorar la calidad: Garantiza que el producto final cumple exactamente con lo que el negocio pidió.
- Facilitar auditorías y cumplimiento: En proyectos regulados (banca, salud, gobierno), la trazabilidad es obligatoria para demostrar que todo fue validado.
- Medir avance real: Puedes saber:
- % de requisitos implementados
- % de requisitos probados
- % de requisitos aprobados
Tipos de trazabilidad
- Hacia adelante (Forward Traceability): Requisito → Diseño → Desarrollo → Pruebas
- Hacia atrás (Backward Traceability): Caso de prueba → Requisito origen (Muy útil para evitar desarrollar funcionalidades no solicitadas)
La trazabilidad nos sirve para:
- ✔ Asegurar cobertura total
- ✔ Controlar cambios
- ✔ Reducir riesgos
- ✔ Mejorar calidad
- ✔ Tener visibilidad y control del proyecto
Métricas y KPIs de Calidad
El Gobierno de QA recibirá y visualizará periódicamente:
Densidad de defectos
Bugs en general Vs Sprint
Son los defectos detectados durante la ejecución del sprint actual, relacionados con las historias de usuario, tareas o cambios desarrollados en ese mismo ciclo. Es cualquier desviación entre el comportamiento esperado (según criterios de aceptación o requisitos) y el comportamiento real del sistema, detectado dentro del sprint activo.
Bugs Abiertos
Son todos los defectos registrados en el sistema de gestión (Azure DevOps, Jra, etc.) que aún no han sido cerrados ni resueltos definitivamente. Es decir, son errores que siguen activos en alguna etapa del flujo de vida del defecto. Es cualquier defecto que se encuentra en estado pendiente dentro del ciclo de vida de un bug, como por ejemplo:
- New
- Open
- To Do
- In Progress
- Reopened
- Ready for Fix
- Retest
Bugs UAT Abiertos
Son los defectos detectados durante la fase de User Acceptance Testing (UAT) que aún no han sido corregidos ni cerrados. Es decir, son errores encontrados por usuarios finales, negocio o stakeholders durante la validación funcional previa a producción y que permanecen abiertos en el sistema de gestión. En otras palabras es un defecto identificado en el entorno de aceptación (UAT) que:
- ✅ Fue reportado formalmente
- ✅ Está asociado a pruebas de aceptación
- ✅ Aún no ha sido resuelto y validado
- ✅ Puede bloquear o condicionar la salida a producción
Los Open Bugs UAT pueden:
- 🚫 Bloquear la salida a producción
- ⚠️ Requerir hotfix antes del Go-Live
- 📊 Afectar la percepción de calidad
- 🔁 Generar replanificación del despliegue
En muchos proyectos, no se permite liberar si existen Open Bugs UAT críticos o altos.
Mejoras Abiertas
Son solicitudes de optimización, ajuste o ampliación de funcionalidades existentes que ya fueron registradas en el sistema de gestión, pero que aún no han sido implementadas ni cerradas. No son errores del sistema, sino oportunidades de mejora detectadas por usuarios, negocio, QA o el equipo técnico. Una Mejora Abierta es un requerimiento de cambio o mejora que:
- ✅ Está documentado formalmente (Azure DevOps, Jira, etc.)
- ✅ Aún no ha sido desarrollado o implementado
- ✅ No corresponde a un defecto funcional
- ✅ Busca optimizar experiencia, eficiencia o funcionalidad
Se debe de:
- Diferenciar claramente bug vs mejora al reportar.
- Documentar el beneficio esperado.
- Adjuntar evidencia o caso de uso.
- Ayudar a negocio a estimar impacto y prioridad.
- Evitar clasificar como bug algo que es realmente una mejora.
Riesgos identificados
Son eventos o condiciones potenciales que podrían afectar negativamente la calidad del producto, el cumplimiento del alcance, los tiempos o la estabilidad del sistema si llegan a materializarse. No son problemas actuales (como los bugs), sino posibles problemas futuros que deben ser gestionados preventivamente. Un riesgo identificado es una amenaza documentada que:
- ✅ Tiene una probabilidad de ocurrencia
- ✅ Tiene un impacto potencial en el proyecto o producto
- ✅ Puede mitigarse o reducirse con acciones preventivas
En QA, los riesgos están directamente relacionados con la calidad, cobertura de pruebas, dependencias técnicas o estabilidad del entorno. Por lo que QA deberá:
- Identificar riesgos desde la planificación del sprint.
- Documentarlos en el Test Plan.
- Asignar planes de mitigación claros.
- Reevaluarlos en cada ceremonia ágil.
- Comunicar riesgos críticos de forma temprana.
Bugs de Automatización
Es un defecto que ocurre dentro del framework, script o entorno de pruebas automatizadas, y no necesariamente en la aplicación bajo prueba. Es decir, el fallo está en la automatización, no en el sistema funcional. Un Bug de Automatización es un error que provoca que una prueba automatizada:
- Falla incorrectamente (falso positivo)
- Pase incorrectamente (falso negativo)
- No pueda ejecutarse
- Se comporte de forma inestable (flaky test)
Y cuya causa raíz está en el código de automatización o en su configuración. Sus causas comunes son:
- Cambios en la UI sin actualizar los locators.
- Falta de manejo adecuado de esperas dinámicas.
- Código duplicado o mal estructurado.
- Problemas en el ambiente (red, servicios externos).
- Mala gestión de datos de prueba.
Un Bug de Automatización no indica que el producto esté defectuoso, sino que la prueba automatizada necesita corrección o mantenimiento.
Severidad promedio
Es una métrica que indica el nivel promedio de impacto técnico de los defectos detectados en un periodo determinado (sprint, release, proyecto). Sirve para entender qué tan graves son los bugs encontrados, más allá de la cantidad. La severidad mide el impacto técnico del defecto en el sistema, por ejemplo:
- Crítica → El sistema se cae o una funcionalidad clave no funciona.
- Alta → Funcionalidad importante afectada sin workaround.
- Media → Funcionalidad afectada con workaround disponible.
- Baja → Error menor (UI, texto, alineación, etc.).
La severidad la define normalmente QA y es el resultado de asignar un valor numérico a cada nivel de severidad y calcular el promedio de los defectos reportados. Los valores que se asignan a la severidad son:
- Crítica = 4
- Alta = 3
- Media = 2
- Baja = 1
Ejemplo de cálculo: Si en un sprint se detectan:
- 2 bugs críticos (4) = 8
- 3 bugs altos (3) = 9
- 4 bugs medios (2) = 8
- 1 bug bajo (1) = 1
Cálculo (fórmula en texto plano):
Se calcula el promedio ponderado el cual es 2.6. Una severidad promedio de 2.6 indica que:
- El nivel general de impacto está entre Media (2) y Alta (3).
- Existe presencia relevante de defectos críticos y altos.
- No es un escenario de bajo riesgo.
- Requiere análisis antes de una liberación.
Es decir:
- Severidad promedio alta → Problemas graves en el sistema.
- Severidad promedio baja → Mayoría de defectos menores.
- Severidad estable y baja en el tiempo → Producto maduro.
La Severidad Promedio ayuda a:
- 📊 Medir la calidad real del producto.
- 📈 Evaluar estabilidad entre sprints.
- 🔎 Detectar si los bugs son superficiales o estructurales.
- 🚦 Apoyar decisiones de Go/No-Go.
- 📉 Analizar tendencias de mejora o deterioro.
Tiempo medio de resolución
También conocida como MTTR (Mean Time To Resolve) — mide el promedio de tiempo que tarda un defecto en ser resuelto desde que se reporta hasta que se cierra. Es una métrica clave para evaluar la eficiencia del proceso de gestión de defectos.
El Tiempo Medio de Resolución es: El tiempo promedio transcurrido entre la fecha de creación del bug y su fecha de cierre validado por QA. Incluye normalmente:
- Registro del bug
- Análisis
- Desarrollo del fix
- Deploy
- Retest
- Cierre
Fórmula: $$\text{TMR} = \frac{\sum (\text{Tiempo de resolución de cada bug})}{\text{Total de bugs cerrados}}$$
- Por ejemplo:
Si 3 bugs tardaron:
- Bug 1 → 2 días
- Bug 2 → 4 días
- Bug 3 → 6 días $$\text{TMR} = \frac{2 + 4 + 6}{3} = 4\text{ días}$$
Este valor mide:
- ⚡ Velocidad de respuesta del equipo
- 🔄 Eficiencia del flujo de defectos
- 🛠 Capacidad de resolución técnica
- 🤝 Coordinación entre QA y desarrollo
La interpretación de este valor es:
- TMR bajo → Proceso ágil y eficiente.
- TMR alto → Cuellos de botella, dependencias o sobrecarga.
- TMR variable → Falta de estabilidad en el proceso.
El Tiempo Medio de Resolución indica qué tan rápido el equipo transforma un defecto reportado en un problema cerrado y validado, siendo un indicador clave de madurez operativa y eficiencia del proceso QA-Dev.
Defectos en producción (escape rate)
El Escape Rate (también llamado Defect Escape Rate o Defect Leakage) es una métrica que mide el porcentaje de defectos que no fueron detectados durante las fases de testing y que “escapan” a producción. En otras palabras: “La proporción de bugs encontrados en producción respecto al total de bugs detectados antes y después de la liberación.”
Fórmula: $$\text{Escape Rate (%)} = \left(\frac{\text{Bugs encontrados en Producción}}{\text{Total de bugs encontrados}}\right) \times 100$$
Donde: $$\text{Total de bugs} = \text{Bugs encontrados en QA} + \text{Bugs encontrados en Producción}$$
Es un indicador directo de la efectividad del proceso de QA.
Ejemplo práctico:
- 80 bugs se detectaron en QA
- 20 bugs se detectaron en Producción
- Total de bugs = 100
$$\text{Escape Rate} = \left(\frac{20}{100}\right) \times 100 = 20%$$
Esto significa que el 20% de los defectos escaparon a producción.
Mide:
- 🎯 Efectividad del testing
- 📊 Calidad del proceso de validación
- 🔍 Cobertura de pruebas
- 🧪 Capacidad de detección temprana
- 📈 Riesgo de impacto en usuarios finales
Cobertura de pruebas automatizadas (% automatización)
Es la métrica que indica qué porcentaje del sistema, funcionalidades o flujos críticos están validados mediante pruebas automáticas. La cobertura de pruebas automatizadas mide el alcance del testing automático sobre el producto, ya sea en términos de:
- Funcionalidades
- Historias de usuario
- Requisitos
- Flujos críticos
- Código fuente (si hablamos de cobertura técnica)
Tipos de cobertura:
- 1️⃣ Cobertura funcional: Mide qué porcentaje de funcionalidades o historias están automatizadas.
- Ejemplo: Si en un módulo hay 20 historias y 15 tienen pruebas automatizadas: $$\text{Cobertura funcional} = \left(\frac{15}{20}\right) \times 100 = 75%$$
- 2️⃣ Cobertura de regresión: Indica qué porcentaje de los escenarios críticos están protegidos por automatización en cada release. Muy utilizada en equipos ágiles.
- 3️⃣ Cobertura de código (coverage técnica): Más técnica, mide qué porcentaje del código fue ejecutado durante pruebas automatizadas. Incluye:
- Line coverage
- Branch coverage
- Path coverage
- Ejemplo: El 80% del código fue ejecutado durante la suite automatizada.
La cobertura automatizada permite:
- 🚀 Detectar regresiones rápidamente.
- 🔁 Ejecutar pruebas frecuentes en CI/CD.
- 📉 Reducir riesgo en producción.
- ⏱ Acelerar releases.
- 🔒 Proteger flujos críticos.
La Cobertura de Pruebas Automatizadas mide qué tanto del sistema está protegido por validaciones automáticas, ayudando a reducir riesgo, acelerar entregas y mejorar estabilidad.
Cumplimiento de DoD
Es la métrica que indica qué tan consistentemente las historias o incrementos entregados cumplen con todos los criterios establecidos para considerarse “terminados” dentro del equipo ágil. La DoD es un acuerdo del equipo que define cuándo una historia puede pasar a estado “Done”.
Normalmente incluye criterios como:
- ✅ Desarrollo completado
- ✅ Code review aprobado
- ✅ Pruebas unitarias ejecutadas
- ✅ Pruebas funcionales ejecutadas
- ✅ Sin bugs críticos o altos abiertos
- ✅ Documentación actualizada
- ✅ Pruebas automatizadas agregadas (si aplica)
- ✅ Deploy en ambiente de QA validado
Mide el porcentaje de historias que cumplen todos los puntos de la DoD sin excepciones.
Fórmula básica: $$\text{Cumplimiento DoD (%)} = \left(\frac{\text{Historias que cumplen completamente la DoD}}{\text{Total de historias del sprint}}\right) \times 100$$
Ejemplo: En un sprint se entregan 10 historias: 8 cumplen todos los criterios de DoD y 2 tienen bugs altos abiertos. $$\text{Cumplimiento DoD} = \left(\frac{8}{10}\right) \times 100 = 80%$$
Con esta métrica se evita:
- Historias “semi-terminadas”
- Deuda técnica acumulada
- Bugs arrastrados al siguiente sprint
- Incrementos inestables
- Falsas percepciones de avance
Un sprint con alta velocidad, pero bajo cumplimiento de DoD no es saludable. El Cumplimiento de DoD mide disciplina, calidad real y madurez del equipo ágil. No evalúa cuánto se entregó, sino qué tan bien se entregó.
Índice de retrabajo
Es una métrica que mide el porcentaje de trabajo que debe rehacerse o corregirse debido a errores, defectos o incumplimiento de criterios definidos, después de haber sido considerado inicialmente como terminado. El Índice de Retrabajo representa la proporción de esfuerzo invertido en corregir entregables que no cumplieron con los estándares de calidad, requisitos o Definition of Done.
Puede aplicarse a:
- Historias de usuario
- Bugs reabiertos
- Cambios posteriores a aprobación
- Ajustes por mala interpretación de requerimientos
Fórmula: $$\text{Índice de Retrabajo (%)} = \left(\frac{\text{Historias o tareas reabiertas}}{\text{Total de historias cerradas}}\right) \times 100$$
Ejemplo práctico: En un sprint: 20 historias cerradas y 5 fueron reabiertas por defectos. $$\text{Índice de retrabajo} = \left(\frac{5}{20}\right) \times 100 = 25%$$ Eso indica que 1 de cada 4 historias requirió retrabajo.
Qué es lo que mide:
- 📉 Calidad inicial del desarrollo
- 🔍 Claridad de requisitos
- ✅ Efectividad de la validación QA
- 🤝 Alineación entre negocio, QA y desarrollo
- 📊 Madurez del proceso
Cobertura de pruebas por sprint
Es la métrica que indica qué porcentaje del alcance comprometido en un sprint fue efectivamente validado mediante pruebas (manuales y/o automatizadas) antes de su cierre. La Cobertura de pruebas por sprint mide la proporción de historias, funcionalidades o criterios de aceptación del sprint que fueron ejecutados y validados por QA. Se enfoca en el alcance del sprint actual, no en todo el producto.
Formas comunes de medirla:
- 1️⃣ Por historias de usuario: $$\text{Cobertura (%)} = \left(\frac{\text{Historias probadas}}{\text{Total de historias comprometidas}}\right) \times 100$$ Ejemplo: 12 historias comprometidas y 10 fueron probadas completamente $\rightarrow \text{Cobertura} = \left(\frac{10}{12}\right) \times 100 = 83%$
- 2️⃣ Por casos de prueba: $$\text{Cobertura (%)} = \left(\frac{\text{Casos ejecutados}}{\text{Casos planificados}}\right) \times 100$$ Ejemplo: 50 casos planificados y 45 ejecutados $\rightarrow \text{Cobertura} = 90%$
- 3️⃣ Por criterios de aceptación: $$\text{Cobertura (%)} = \left(\frac{\text{Criterios validados}}{\text{Total de criterios definidos}}\right) \times 100$$ Esta es una de las formas más precisas en entornos ágiles.
Interpretación:
- 100% cobertura → Todo el alcance fue probado.
- <90% → Riesgo potencial.
- <80% → Sprint con validación incompleta.
Lo que mide esta métrica:
- 📊 Nivel de validación del incremento del sprint
- ✅ Disciplina del proceso QA
- ⏱ Capacidad de testing dentro del timebox
- 🚦 Riesgo de liberar funcionalidades parcialmente probadas
La Cobertura de pruebas por sprint mide qué tan completamente el equipo validó lo que prometió entregar en ese ciclo, siendo un indicador clave de control de calidad dentro del marco ágil.
Planes de prueba
La métrica asociada a Planes de Prueba mide el nivel de planificación, preparación y control del proceso de testing antes de la ejecución. No mide defectos directamente, sino la madurez y disciplina en la estrategia de pruebas.
Qué mide la métrica de planes de prueba (dependiendo del enfoque organizacional):
- 1️⃣ Cumplimiento de Planes de Prueba: % de proyectos o sprints que cuentan con plan de pruebas formalmente definido. $$\text{Fórmula: } \left(\frac{\text{Planes elaborados}}{\text{Proyectos o sprints totales}}\right) \times 100$$
- 2️⃣ Nivel de ejecución del plan: Mide qué tanto del plan fue realmente ejecutado. $$\text{Fórmula: } \left(\frac{\text{Casos ejecutados}}{\text{Casos planificados}}\right) \times 100$$
- 3️⃣ Desviación del plan: Mide diferencias entre lo planificado y lo realmente ejecutado:
- Tiempo estimado vs real
- Casos planificados vs ejecutados
- Alcance definido vs probado
- 4️⃣ Cobertura definida en el plan: Evalúa si el plan cubre:
- Requisitos funcionales
- No funcionales
- Integraciones
- Riesgos identificados
Qué mide realmente esta métrica:
- 📋 Nivel de planificación del QA
- 📊 Capacidad de estimación
- 📈 Madurez del proceso de calidad
- 🎯 Control del alcance de pruebas
- ⚖ Gestión de riesgos
Interpretación:
- Alta adherencia al plan → Proceso controlado y predecible.
- Alta desviación → Problemas de estimación o cambios frecuentes.
- Ausencia de plan → Riesgo alto de pruebas improvisadas.
En equipos ágiles el “Plan de Pruebas” puede ser más liviano y puede ser ajustado por el QA:
- Ajustar el plan según riesgo.
- Revisarlo al inicio del sprint.
- Actualizarlo ante cambios relevantes.
- Usarlo como herramienta de gestión, no como formalidad.
- Medir cumplimiento sin burocratizar el proceso.
- Estrategia por sprint
- Refinar criterios de aceptación
- Matriz de riesgos (si Aplica)
- Checklist de validación
- No siempre es un documento extenso, pero sí debe existir claridad estratégica.
La métrica de Planes de Prueba evalúa qué tan bien planificado, estructurado y controlado está el proceso de testing, siendo un indicador de madurez organizacional y prevención de riesgos.
Estos indicadores serán revisados en comités de calidad y utilizados para planes de mejora. Estas métricas serán presentadas mensualmente a Dirección.
Automatización
La compañía define como estándar:
- Automatización mínima obligatoria de pruebas Smoke.
- Integración con pipelines CI/CD.
- Framework corporativo unificado.
- Repositorio centralizado de automatización.
El objetivo es alcanzar progresivamente un X% de regresión automatizada (definir meta realista, por ejemplo 40-60%).
Gestión de Ambientes y Datos
- Los ambientes de prueba deben estar controlados y versionados.
- Los datos de prueba deben cumplir políticas de seguridad y privacidad.
- No se permite usar datos productivos sin anonimización.
Cumplimiento
El incumplimiento de esta política deberá ser reportado al Gobierno de QA o comité de calidad, teniendo las siguientes implicaciones:
- Será registrado en auditorías internas.
- Generará planes de acción correctivos.
- Será reportado a dirección si impacta calidad productiva.
La adopción del modelo de Gobierno de QA es obligatoria y forma parte del marco operativo corporativo.
Compromiso Ejecutivo
La Dirección reconoce que:
- La calidad impacta directamente el negocio.
- La inversión en QA reduce costos de retrabajo.
- La disciplina en pruebas mejora la reputación y confiabilidad.
La compañía se compromete a proporcionar:
- Recursos adecuados.
- Capacitación continua.
- Herramientas oficiales.
- Apoyo organizacional al Gobierno QA.
Declaración Final
Esta Política Corporativa de QA institucionaliza la calidad como un pilar estratégico del negocio, asegurando que la agilidad en SCRUM y la velocidad de DevOps estén respaldadas por control, trazabilidad, automatización y mejora continua, garantizando entregas predecibles, seguras y de alto valor para el cliente.
Esta Política de Calidad no busca generar burocracia, sino:
- Reducir defectos en producción.
- Aumentar previsibilidad en entregas.
- Disminuir retrabajo.
- Incrementar satisfacción del cliente.
- Proteger la reputación corporativa.
La calidad no es un rol, es un sistema.