Por Qué el Testing Necesita Gates
Imagina comenzar system testing solo para descubrir que el entorno de pruebas no está configurado, o que la mitad de las funcionalidades aún están siendo desarrolladas. Desperdiciarías días antes de que cualquier testing significativo pudiera ocurrir. Ahora imagina declarar el testing como “completo” sin una definición clara de qué significa “completo” — cada stakeholder tendría una opinión diferente.
Los criterios de entrada y salida resuelven ambos problemas. Son los gates (puertas de control) que determinan cuándo una fase de testing comienza y cuándo puede terminar.
¿Qué Son los Criterios de Entrada?
Los criterios de entrada son las precondiciones que deben cumplirse antes de que una fase específica de testing pueda comenzar. Responden la pregunta: "¿Estamos listos para empezar?"
Piensa en los criterios de entrada como un checklist en una puerta. Si todos los ítems están marcados, la puerta se abre y el testing procede. Si faltan ítems, el equipo debe resolverlos primero.
Criterios de entrada comunes incluyen:
- Los requisitos están revisados y aprobados
- El entorno de pruebas está configurado y accesible
- Los datos de prueba están preparados
- Los casos de prueba están escritos y revisados
- El build está desplegado y el smoke test pasó
- Todos los defectos bloqueantes de la fase anterior están resueltos
¿Qué Son los Criterios de Salida?
Los criterios de salida son las condiciones que deben cumplirse para considerar una fase de testing como completa. Responden la pregunta: "¿Terminamos?"
Sin criterios de salida, “terminado” se vuelve subjetivo. Una persona podría pensar que 80% de ejecución de pruebas es suficiente; otra podría insistir en 100%. Los criterios de salida eliminan la ambigüedad estableciendo umbrales objetivos y medibles.
Criterios de salida comunes incluyen:
- Un porcentaje definido de casos de prueba se han ejecutado (ej., 95%)
- No hay defectos abiertos de severidad Critical o High
- La densidad de defectos está por debajo de un umbral acordado
- Todos los tipos de prueba planificados (funcional, regresión, performance) están completados
- El reporte resumen de pruebas está preparado y revisado
Criterios de Entrada y Salida por Fase del STLC
Los criterios específicos varían según la fase de testing. A continuación una tabla de referencia completa.
Unit Testing
| Criterios de Entrada | Criterios de Salida |
|---|---|
| El módulo de código está completo y compila | Todas las pruebas unitarias pasan |
| El framework de unit testing está configurado | La cobertura de código cumple el objetivo (ej., 80%) |
| La revisión de estándares de código está hecha | No hay defectos críticos en el módulo |
Integration Testing
| Criterios de Entrada | Criterios de Salida |
|---|---|
| Unit testing está completo (criterios de salida cumplidos) | Todos los casos de integration testing ejecutados |
| Los módulos a integrar están disponibles | Los defectos de interfaz están resueltos |
| El plan de integration testing está aprobado | El flujo de datos entre módulos está verificado |
| El entorno de pruebas soporta integración | Reporte resumen preparado |
System Testing
| Criterios de Entrada | Criterios de Salida |
|---|---|
| Integration testing está completo | 95%+ de casos de prueba ejecutados |
| Build completo desplegado en entorno de pruebas | No hay defectos abiertos Critical/High |
| Plan y casos de system testing revisados | Todos los requisitos funcionales verificados |
| Datos de prueba preparados | Requisitos no funcionales validados |
| Matriz de trazabilidad actualizada | Reporte resumen aprobado |
User Acceptance Testing (UAT)
| Criterios de Entrada | Criterios de Salida |
|---|---|
| Criterios de salida de system testing cumplidos | Todos los escenarios UAT ejecutados |
| Entorno UAT replica producción | Los stakeholders de negocio dan sign-off |
| Usuarios de negocio entrenados y disponibles | No hay defectos abiertos que bloqueen procesos de negocio |
| Escenarios UAT aprobados por el negocio | Decisión de go-live documentada |
¿Quién Define los Criterios?
Los criterios de entrada y salida no los crea una sola persona de forma aislada. Emergen de la colaboración:
El QA Lead típicamente prepara el borrador inicial de los criterios basándose en experiencia y estándares de la industria. Luego el equipo los revisa y ajusta. Los criterios finales acordados se documentan en el plan de pruebas y se comparten con todos los stakeholders.
Principio clave: los criterios deben ser medibles y objetivos. “Calidad suficientemente buena” no es un criterio válido. “Cero defectos críticos y menos de 5 defectos de alta severidad” sí lo es.
Ejemplos Prácticos
Ejemplo 1: Feature de Checkout en E-Commerce
Criterios de entrada para system testing:
- La integración con el payment gateway está completa
- Los números de tarjeta de crédito de prueba están configurados en sandbox
- El flujo de checkout está desplegado en el entorno de staging
- Los casos de prueba cubren todos los métodos de pago (tarjeta de crédito, PayPal, Apple Pay)
Criterios de salida para system testing:
- Todos los escenarios de checkout probados en 3 navegadores
- Procesamiento de pagos verificado para todas las monedas soportadas
- No hay defectos con severidad Critical o High
- Performance: el checkout se completa en menos de 3 segundos
Ejemplo 2: App de Banca Móvil
Criterios de entrada para UAT:
- Los criterios de salida de system testing se cumplen
- El entorno UAT usa datos similares a producción (anonimizados)
- Los testers de negocio tienen cuentas y dispositivos de prueba
- Las verificaciones de cumplimiento regulatorio están documentadas
Criterios de salida para UAT:
- Los 50 escenarios UAT ejecutados por usuarios de negocio
- Sign-off obtenido de Cumplimiento, Operaciones y Producto
- Cualquier defecto diferido tiene workarounds documentados
- Checklist de go-live completado
¿Qué Pasa Cuando los Criterios No Se Cumplen?
Cuando los criterios de entrada no se cumplen completamente, el equipo tiene tres opciones:
- Esperar — retrasar la fase hasta que todos los criterios se cumplan
- Proceder con riesgo — iniciar el testing con riesgos documentados y un plan de mitigación
- Dispensar criterios específicos — acordar formalmente omitir un criterio con aprobación de stakeholders
La decisión debe documentarse. En la mayoría de las organizaciones, proceder con criterios no cumplidos requiere aprobación del project manager o comité directivo.
Cuando los criterios de salida no se cumplen, el equipo enfrenta una decisión similar: continuar el testing, liberar con riesgos conocidos, o extender el cronograma.
Mejores Prácticas
- Define criterios temprano — inclúyelos en el plan de pruebas, no como algo de último momento
- Mantén criterios medibles — usa números, porcentajes y condiciones específicas
- Obtén acuerdo de stakeholders — los criterios solo funcionan si todos los aceptan
- Revisa y actualiza — ajusta criterios conforme el proyecto evoluciona
- Rastrea el progreso — monitorea métricas de criterios de salida diariamente durante el testing
- Documenta desviaciones — si se dispensan criterios, registra quién aprobó y por qué
Errores Comunes
- Criterios demasiado estrictos — requerir 100% de pass rate cuando 95% es realista
- Criterios demasiado laxos — permitir que defectos críticos pasen
- No documentar criterios — los acuerdos verbales se olvidan
- Ignorar criterios bajo presión — cuando los deadlines se acercan, los criterios son la primera víctima
- Criterios genéricos — diferentes proyectos y fases necesitan diferentes umbrales
Ejercicio: Define Criterios de Entrada y Salida
Escenario: Eres el QA Lead de una nueva funcionalidad en un portal de pacientes de salud. La funcionalidad permite a los pacientes ver y descargar sus resultados de laboratorio como PDF. El portal maneja datos médicos sensibles (regulado por HIPAA).
Tu tarea: Define criterios de entrada y salida para system testing y UAT de esta funcionalidad.
Considera:
- ¿Qué hace a este proyecto de alto riesgo?
- ¿Qué criterios relacionados con seguridad deben incluirse?
- ¿Qué requisitos de cumplimiento afectan los criterios?
- ¿Qué tan estricto debe ser el umbral de defectos?
Escribe tus criterios en formato de tabla para cada fase.
Pista
Piensa en los aspectos únicos del software de salud:
- El cumplimiento de HIPAA requiere audit trails y controles de acceso
- La precisión de datos médicos es crítica (resultados de laboratorio incorrectos podrían dañar pacientes)
- La generación de PDF debe probarse para integridad de datos
- El security testing (penetration testing, controles de acceso) debe ser un criterio de entrada o salida
Solución
System Testing — Criterios de Entrada
| # | Criterio |
|---|---|
| 1 | La integración de resultados de laboratorio con la API backend está completa |
| 2 | El módulo de generación de PDF está desplegado y funcional |
| 3 | El entorno de pruebas configurado con logging compatible con HIPAA |
| 4 | Los datos de prueba contienen resultados de laboratorio anonimizados pero realistas |
| 5 | Los casos de prueba de seguridad (control de acceso, encriptación) están revisados |
| 6 | El checklist de cumplimiento HIPAA está disponible |
| 7 | El smoke test pasa en el build |
System Testing — Criterios de Salida
| # | Criterio |
|---|---|
| 1 | 100% de los casos de prueba de ruta crítica ejecutados (ver, descargar, imprimir) |
| 2 | 95% de ejecución total de casos de prueba |
| 3 | Cero defectos abiertos Critical o High |
| 4 | Security testing completo: no es posible acceso no autorizado |
| 5 | El contenido del PDF coincide con los registros de base de datos (integridad verificada) |
| 6 | El audit trail captura todos los accesos a resultados de laboratorio |
| 7 | Performance: el PDF se genera en menos de 5 segundos |
UAT — Criterios de Entrada
| # | Criterio |
|---|---|
| 1 | Criterios de salida de system testing cumplidos |
| 2 | El entorno UAT usa datos similares a producción (registros reales anonimizados) |
| 3 | El personal clínico y representantes de pacientes están entrenados |
| 4 | El oficial de cumplimiento está disponible para revisión |
| 5 | Los escenarios UAT aprobados por equipos médicos y de cumplimiento |
UAT — Criterios de Salida
| # | Criterio |
|---|---|
| 1 | Todos los escenarios UAT ejecutados por personal clínico |
| 2 | Los flujos del paciente verificados por representantes de pacientes |
| 3 | Sign-off del oficial de cumplimiento sobre requisitos HIPAA |
| 4 | Cero defectos que puedan llevar a mostrar datos médicos incorrectos |
| 5 | Requisitos de accesibilidad verificados (WCAG 2.1 AA) |
| 6 | Decisión go/no-go documentada con firmas de todos los stakeholders |
Por qué estos criterios son apropiados:
- Más estrictos que proyectos típicos por la regulación HIPAA y seguridad del paciente
- 100% de ejecución en rutas críticas (no solo 95%) porque la precisión de datos médicos no es negociable
- Incluye criterios de salida específicos de cumplimiento que proyectos estándar no necesitarían
- Requiere sign-off explícito de stakeholders clínicos y de cumplimiento
Puntos Clave
- Los criterios de entrada previenen inicios prematuros; los criterios de salida previenen finalizaciones prematuras
- Los criterios deben ser medibles, documentados y acordados por los stakeholders
- Diferentes fases del STLC necesitan diferentes criterios
- Las industrias reguladas requieren criterios más estrictos y específicos
- Cuando los criterios no se pueden cumplir, documenta la desviación y obtén aprobación formal