32.1 Introducción
Las pruebas de integración no terminan simplemente cuando se ejecutan algunos casos. El equipo necesita criterios claros para decidir si la integración está suficientemente verificada, qué riesgos quedan pendientes y qué información debe comunicarse.
Los criterios de finalización ayudan a evitar decisiones basadas solo en impresiones. El reporte de resultados permite compartir evidencia, defectos, bloqueos y conclusiones con el equipo.
En este tema veremos cómo definir criterios de finalización y cómo reportar resultados de pruebas de integración de forma útil.
32.2 Qué son los criterios de finalización
Los criterios de finalización son condiciones que deben cumplirse para considerar terminada una actividad de prueba.
En integración, pueden responder preguntas como:
- ¿Se ejecutaron los escenarios críticos?
- ¿Las integraciones principales pasaron?
- ¿Los defectos graves fueron corregidos?
- ¿Quedan riesgos aceptados por el equipo?
- ¿El ambiente fue suficientemente estable?
- ¿Hay evidencia para respaldar la decisión?
Finalizar pruebas no significa demostrar que no existen errores. Significa contar con información suficiente para tomar una decisión responsable.
32.3 Por qué son necesarios
Sin criterios claros, las pruebas pueden terminar demasiado pronto o extenderse sin una meta concreta.
Los criterios ayudan a:
- Definir expectativas antes de ejecutar.
- Priorizar escenarios importantes.
- Evitar discusiones subjetivas.
- Comunicar riesgos pendientes.
- Decidir si una versión puede avanzar.
- Registrar por qué se tomó una decisión.
32.4 Criterios basados en ejecución
Un criterio habitual es verificar que se hayan ejecutado los casos planificados para la integración.
Ejemplos:
- Se ejecutaron todos los escenarios críticos definidos.
- Se ejecutaron las pruebas de integración de compra, pago y stock.
- Se ejecutaron casos positivos, negativos y límites prioritarios.
- Se ejecutaron pruebas con dependencias simuladas y pruebas contra sandbox cuando correspondía.
Este criterio debe combinarse con resultados y riesgos. Ejecutar todo no alcanza si hay fallas importantes abiertas.
32.5 Criterios basados en resultados
Otro criterio es el estado de los resultados obtenidos.
Por ejemplo:
- El 100% de escenarios críticos pasó.
- No hay defectos bloqueantes abiertos.
- No hay defectos graves sin plan de corrección.
- Las fallas conocidas tienen impacto analizado.
- Las pruebas inestables fueron investigadas o excluidas con justificación.
Es importante diferenciar una prueba fallida por defecto real de una prueba fallida por ambiente mal preparado.
32.6 Criterios basados en riesgo
Las pruebas de integración se priorizan por riesgo. Por eso, la finalización también debe considerar riesgos.
Preguntas útiles:
- ¿Las integraciones de mayor impacto fueron verificadas?
- ¿Quedan dependencias externas sin probar?
- ¿Hay contratos cambiados sin validación?
- ¿Hay defectos conocidos que podrían afectar datos críticos?
- ¿El equipo acepta explícitamente los riesgos pendientes?
Un riesgo no desaparece por no probarlo. Debe ser probado, mitigado o aceptado conscientemente.
32.7 Criterios basados en ambiente
El ambiente puede condicionar la validez de los resultados. Si el ambiente fue inestable, los resultados deben interpretarse con cuidado.
Se puede considerar:
- Ambiente disponible durante la ejecución.
- Datos de prueba preparados correctamente.
- Dependencias reales o simuladas funcionando.
- Versiones de servicios conocidas.
- Configuración correcta.
- Ausencia de interferencias importantes.
Si el ambiente no fue confiable, quizá no corresponda concluir que la integración está validada.
32.8 Criterios de entrada y salida
Además de criterios de finalización, muchas veces conviene definir criterios de entrada. Los criterios de entrada indican cuándo estamos en condiciones de empezar a probar.
| Tipo |
Ejemplo |
| Criterio de entrada |
Servicios desplegados, base actualizada y datos iniciales disponibles. |
| Criterio de salida |
Escenarios críticos ejecutados sin defectos bloqueantes. |
Definir ambos evita comenzar pruebas sobre un ambiente que todavía no puede entregar resultados confiables.
32.9 Qué debe incluir un reporte
Un reporte de pruebas de integración debe ser claro y útil para tomar decisiones.
Puede incluir:
- Alcance probado.
- Componentes integrados.
- Ambiente utilizado.
- Casos ejecutados.
- Resultados obtenidos.
- Defectos encontrados.
- Riesgos pendientes.
- Conclusión o recomendación.
32.10 Reportar alcance
El reporte debe indicar qué se probó y qué no se probó. Esto evita falsas conclusiones.
Ejemplo de alcance:
- Se probó integración entre compras, stock y base de datos.
- El proveedor de pagos fue simulado.
- No se probó envío real de correos.
- Se validó publicación de evento de orden creada.
- No se ejecutaron pruebas de rendimiento.
Decir qué quedó fuera es tan importante como decir qué se cubrió.
32.11 Reportar resultados
Los resultados deben presentarse de forma concreta. No alcanza con decir “la mayoría pasó”.
Un resumen puede indicar:
- Total de casos planificados.
- Casos ejecutados.
- Casos pasados.
- Casos fallidos.
- Casos bloqueados.
- Casos no ejecutados y motivo.
Si hay pocas pruebas pero muy críticas, conviene explicar impacto además de cantidad.
32.12 Reportar defectos
Los defectos deben reportarse con información suficiente para reproducir y entender el problema.
Un reporte de defecto debería incluir:
- Descripción clara.
- Componentes involucrados.
- Datos usados.
- Resultado esperado.
- Resultado obtenido.
- Evidencia disponible.
- Impacto estimado.
En integración, también conviene indicar si la sospecha apunta a contrato, datos, configuración, dependencia o lógica.
32.13 Reportar bloqueos
Un caso bloqueado no es lo mismo que un caso fallido. Está bloqueado cuando no pudo ejecutarse por una condición externa al comportamiento probado.
Ejemplos:
- Ambiente caído.
- Base de datos sin migraciones.
- Servicio dependiente no desplegado.
- Credenciales de prueba faltantes.
- Datos iniciales no disponibles.
El reporte debe separar defectos del sistema y bloqueos de ejecución.
32.14 Reportar riesgos pendientes
Cuando algo no se pudo probar o quedó parcialmente cubierto, debe reportarse como riesgo pendiente.
Ejemplos:
- No se probó integración real con proveedor de pagos, solo simulación.
- No se ejecutaron pruebas asíncronas por indisponibilidad de cola.
- No se probó concurrencia en descuento de stock.
- Queda pendiente validar contrato con nuevo servicio de facturación.
Reportar riesgos permite que el equipo decida si avanza, corrige, posterga o ejecuta pruebas adicionales.
32.15 Evidencia en el reporte
La evidencia respalda los resultados. No siempre debe incluirse completa en el cuerpo del reporte, pero debe estar disponible.
Puede incluir:
- Logs relevantes.
- Capturas de respuestas.
- Consultas de estado final.
- Mensajes publicados.
- Archivos generados.
- Identificadores de ejecución.
La evidencia debe proteger datos sensibles y secretos.
32.16 Ejemplo de resumen de resultados
Un resumen simple podría verse así:
| Elemento |
Resultado |
| Alcance |
Compras, stock, pagos simulados y eventos de orden. |
| Casos ejecutados |
18 de 20. |
| Pasados |
15. |
| Fallidos |
2, ambos relacionados con evento duplicado. |
| Bloqueados |
1 por indisponibilidad de cola compartida. |
| Riesgo pendiente |
No se validó proveedor de pagos real en sandbox. |
32.17 Errores comunes
Al cerrar y reportar pruebas de integración, suelen aparecer errores como:
- No definir criterios de finalización antes de ejecutar.
- Reportar solo cantidad de pruebas sin explicar impacto.
- Mezclar fallas del producto con bloqueos del ambiente.
- No informar riesgos pendientes.
- Decir que una integración está validada aunque se usaron simulaciones para dependencias críticas.
- No conservar evidencia de fallas.
- No actualizar el reporte después de reejecuciones.
32.18 Lista de verificación
Antes de cerrar una etapa de pruebas de integración, conviene revisar:
- ¿Los criterios de finalización están definidos?
- ¿Se ejecutaron los escenarios críticos?
- ¿Los defectos graves están corregidos o aceptados con justificación?
- ¿Los bloqueos están separados de los fallos?
- ¿Los riesgos pendientes están explícitos?
- ¿El alcance probado está claro?
- ¿Existe evidencia suficiente para respaldar el resultado?
32.19 Qué debes recordar de este tema
- Los criterios de finalización indican cuándo una actividad de prueba puede considerarse suficientemente cerrada.
- Finalizar no significa garantizar ausencia total de errores.
- El reporte debe indicar alcance, resultados, defectos, bloqueos y riesgos pendientes.
- Los riesgos no probados deben informarse claramente.
- La evidencia respalda los resultados y facilita decisiones.
- Un buen reporte ayuda al equipo a decidir el siguiente paso.
32.20 Conclusión
Los criterios de finalización y el reporte de resultados convierten la ejecución de pruebas en información útil para decidir. No se trata solo de pasar o fallar casos, sino de comunicar el estado real de las integraciones, sus defectos y sus riesgos.
Una integración puede avanzar cuando el equipo entiende qué fue probado, qué resultado se obtuvo y qué incertidumbre queda pendiente.
En el próximo tema veremos buenas prácticas y errores comunes en pruebas de integración.