Testing de Sistema
Evaluar el sistema de punta a punta, no cada componente. Y en qué se diferencia del testing de integración.
Qué es
El testing de sistema evalúa el sistema completo desde una perspectiva funcional. Acá dejamos de pensar en componentes individuales y empezamos a evaluar un comportamiento de punta a punta.
1. Usuario busca disponibilidad (Availability Service)
2. Reserva creada (Reservation API)
3. Seña cobrada (Payment Service)
4. Mesa bloqueada (Table Service)
5. Confirmación enviada (Notification Service)El objetivo no es verificar cada componente por separado, sino que el sistema satisfaga los requisitos funcionales como un todo.
Testing de sistema vs. testing de integración
Esta diferencia genera confusión seguido, así que vale la pena dejarla explícita:
| Foco | |
|---|---|
| Testing de integración | La interacción entre componentes (ReservationService → PostgreSQL) |
| Testing de sistema | Un comportamiento completo del sistema (Usuario → API → múltiples componentes → resultado) |
Un test de sistema puede recorrer varios puntos de integración, pero su objetivo es distinto: no verifica una interacción puntual, sino el resultado final que le llega al usuario.
El costo de subir de nivel
A medida que aumenta el alcance —de unitario a integración a sistema— normalmente aumentan el tiempo de ejecución, la complejidad de configuración, los requisitos de infraestructura y el costo de diagnosticar un fallo. Por eso no conviene convertir toda la suite en tests end-to-end: es exactamente la razón de ser de la pirámide de tests que vimos en la introducción de este tema.
Qué NO detecta
Un test de sistema puede confirmar que el flujo de cancelación de ReservaResto funciona exactamente como está implementado: la seña se reintegra según la regla implementada, la mesa se libera, se notifica al comensal. Lo que no puede confirmar es que esa regla implementada sea la que el negocio realmente necesita. Ahí es donde entra UAT.