Cuando alguien menciona "prueba de integración" en una reunión, no todos entienden lo mismo. Esa confusión nace de mezclar dos preguntas distintas como si fueran una sola: dónde estamos probando y por qué estamos probando [0:11]. Separar esas dos dimensiones permite que cada prueba que planifiques lleve una etiqueta clara, sin ambigüedad, y que todo el equipo hable el mismo idioma.
¿Qué son los niveles de prueba y por qué importa el "dónde"?
Un nivel de prueba es un grupo de actividades de testing organizadas alrededor de una fase del desarrollo [0:28]. Para entenderlo, funciona una analogía con el ensamblaje de un automóvil.
¿Cómo funciona la prueba unitaria?
Primero revisas cada pieza suelta: la bujía, la batería. La prueba unitaria evalúa la pieza más pequeña del software —una función, un método— probada en aislamiento por el desarrollador [0:36]. Si la pieza individual falla, no tiene sentido ensamblar nada más.
¿Qué valida la prueba de integración?
Después verificas que esas piezas funcionen juntas: bujía más batería más motor de arranque. La prueba de integración se enfoca en interfaces y flujo de datos entre componentes [0:51]. Un punto clave: integración puede ocurrir entre módulos internos o entre sistemas completos [1:03]. Cuando alguien dice "prueba de integración" sin especificar cuál, la conversación se complica. Siempre pregunta: ¿qué se está conectando? [1:16]
¿Qué cubren la prueba de sistema y la de aceptación?
- Prueba de sistema: tomas el producto completamente ensamblado y lo llevas a un entorno lo más cercano posible a producción. Cubre funcionalidad y aspectos no funcionales, ejecutada por un equipo independiente [1:18].
- Prueba de aceptación: ya no preguntas si funciona técnicamente, sino si satisface las necesidades reales del negocio. Los responsables son los usuarios o clientes, no el equipo técnico [1:41].
¿Cómo se visualiza la estrategia con la pirámide de pruebas?
La pirámide de pruebas organiza la distribución ideal: muchas pruebas unitarias rápidas en la base, menos de integración en el medio y pocas de sistema en la cima [1:53]. Cuanto más alto en la pirámide, más lenta y compleja resulta la prueba [2:03].
Ejecutarlas en orden —de menor a mayor— a medida que el código avanza desde una rama hacia el despliegue, significa que los problemas se detectan temprano [2:07]. Aquí se materializa el tercer principio del testing: las pruebas tempranas ahorran tiempo y dinero [2:17]. Esa lógica se refleja directamente en la arquitectura del pipeline de integración continua.
¿Qué son los tipos de prueba y cómo se combinan con los niveles?
Un tipo de prueba es un grupo de actividades enfocadas en un objetivo específico de calidad [2:32]. El tipo responde al "por qué" estás probando.
- Prueba funcional: verifica que el software hace lo que debe. Presionas el botón de café y sale café, no jugo [2:37].
- Prueba no funcional: evalúa qué tan bien se comporta el sistema: rendimiento, seguridad, usabilidad [2:45].
- Prueba de regresión: confirma que un cambio no rompió algo que ya funcionaba [2:51].
- Prueba de smoke: verifica las funciones más críticas antes de invertir tiempo en pruebas profundas. Es como encender el carro para confirmar que el motor arranca antes de un viaje largo [2:57].
Piensa en un paquete postal con dos etiquetas: a dónde va y qué contiene. Necesitas ambas [3:08]. El nivel es la dirección, el tipo es el contenido. Si mides cuántos usuarios simultáneos soporta la aplicación completa, la etiqueta correcta es: nivel sistema, tipo rendimiento [3:23]. Si un usuario de negocio verifica el flujo de compra en preproducción, es: nivel aceptación, tipo funcional [3:31].
El error más común es dar solo la mitad. Alguien dice "es una prueba de usabilidad" y se detiene — falta el nivel. Sin él, no sabes quién es responsable ni cómo encaja en el cronograma [3:38].
¿Puede la regresión existir en más de un nivel?
Sí, absolutamente. La regresión es un tipo, no un nivel [3:53]. Al nivel unitario reejecutas pruebas de una función modificada. Al nivel de sistema verificas el producto completo. Mismo objetivo, distinto alcance [4:07]. Por eso los equipos que practican integración continua automatizan regresión en múltiples niveles [4:10].
La próxima vez que etiquetes una prueba, asegúrate de incluir ambas dimensiones. ¿Tu equipo ya maneja esa distinción o todavía se generan malentendidos? Comparte tu experiencia.
