Que Es el Testing de Sistema?
El testing de sistema es el proceso de probar una aplicacion de software completa e integrada para verificar que cumple sus requisitos especificados. A diferencia del unit testing (que se enfoca en funciones individuales) y el testing de integracion (que se enfoca en interacciones entre componentes), el testing de sistema evalua toda la aplicacion como un todo — tal como un usuario o sistema externo interactuaria con ella.
A este nivel, tratas el sistema como una caja negra. No te importa la estructura interna del codigo, los esquemas de base de datos ni como estan conectados los modulos. Te importan las entradas y salidas: dada esta accion, el sistema produce el resultado esperado?
Considera una aplicacion de banca en linea. El testing de sistema verificaria que:
- Un usuario puede iniciar sesion con credenciales validas y es rechazado con invalidas
- Los saldos se muestran correctamente despues de transferencias
- Los pagos programados se ejecutan en las fechas correctas
- Los timeouts de sesion funcionan segun requisitos de seguridad
- La aplicacion maneja multiples monedas correctamente
Testing de Sistema vs Otros Niveles
| Aspecto | Testing de Integracion | Testing de Sistema | Testing E2E |
|---|---|---|---|
| Alcance | Interacciones de componentes | Aplicacion completa | Flujos completos entre sistemas |
| Perspectiva | Desarrollador/Tecnica | QA/Basada en requisitos | Usuario/Negocio |
| Ambiente | Dev/CI | Staging (similar a produccion) | Stack completo similar a produccion |
| Enfoque | Los modulos trabajan juntos? | La app cumple requisitos? | El workflow completo funciona? |
| Base de tests | Documentos de diseno, specs de API | Requisitos, user stories | Procesos de negocio, casos de uso |
La distincion entre testing de sistema y E2E es sutil pero importante. El testing de sistema verifica que tu aplicacion funciona correctamente. El testing E2E verifica que todo el flujo de negocio funciona, lo cual puede abarcar multiples aplicaciones y servicios de terceros.
Tests de Sistema Funcionales
Los tests funcionales verifican que hace el sistema — sus features y comportamientos definidos en requisitos.
Testing de Features
Verificar que cada feature funciona segun lo especificado:
- Login/registro con todos los metodos de autenticacion
- Funcionalidad de busqueda con filtros, ordenamiento y paginacion
- Operaciones del carrito de compras (agregar, eliminar, actualizar cantidades)
- Procesamiento de pagos con varios metodos de pago
- Generacion de reportes con datos correctos y formato adecuado
Validacion de Reglas de Negocio
Verificar que las reglas de negocio se aplican correctamente:
- Reglas de descuento (ej: 10% en ordenes sobre $100, sin combinar con cupones)
- Control de acceso (ej: gerentes aprueban reembolsos hasta $500, directores hasta $5000)
- Validacion de datos (ej: formato de email, numero de telefono, campos obligatorios)
- Reglas de flujo de trabajo (ej: orden no puede enviarse hasta confirmar pago)
Integridad de Datos
Verificar que los datos se almacenan, recuperan y muestran correctamente:
- Registros guardados via UI aparecen correctamente al recuperarlos
- Calculos (totales, impuestos, descuentos) son precisos
- Los datos no se pierden ni corrompen durante operaciones
- Datos historicos se preservan despues de actualizaciones
Tests de Sistema No Funcionales
Los tests no funcionales verifican como se desempena el sistema — atributos de calidad mas alla de la correccion funcional.
Rendimiento
- Tiempo de respuesta bajo carga normal
- Throughput (transacciones por segundo)
- Utilizacion de recursos (CPU, memoria, disco)
Seguridad
- Aplicacion de autenticacion y autorizacion
- Proteccion contra vulnerabilidades comunes (SQL injection, XSS)
- Cifrado de datos en transito y en reposo
- Gestion de sesiones y comportamiento de timeout
Usabilidad
- Intuitividad de la navegacion
- Claridad de mensajes de error
- Cumplimiento de accesibilidad (guias WCAG)
- Consistencia entre paginas
Confiabilidad
- Tiempo medio entre fallas (MTBF)
- Recuperacion de crashes y errores
- Funcionalidad de backup y restauracion de datos
- Degradacion elegante bajo carga
Compatibilidad
- Testing cross-browser (Chrome, Firefox, Safari, Edge)
- Testing cross-dispositivo (desktop, tablet, mobile)
- Testing cross-OS (Windows, macOS, Linux, iOS, Android)
- Compatibilidad de versiones de API
Requisitos de Ambiente
El testing de sistema demanda un ambiente que replique produccion:
Maquinas locales] --> CI[Ambiente CI
Builds automaticos] CI --> STAGING[Staging/QA
Similar a produccion] STAGING --> PROD[Produccion
Usuarios reales] STAGING -.->|Testing de sistema
ocurre aqui| NOTE[Replica produccion:
- Mismo OS y versiones
- Specs de hardware similares
- Datos similares a produccion
- Integraciones reales o stubs realistas]
Consideraciones clave del ambiente:
- Paridad de configuracion: Mismos ajustes que produccion
- Volumen de datos: Suficientes datos para probar paginacion, busqueda y rendimiento
- Topologia de red: Configuracion similar a produccion (firewalls, load balancers)
- Servicios de terceros: Conectados a versiones sandbox/staging de APIs externas
Quien Realiza el Testing de Sistema?
El testing de sistema lo realizan tipicamente ingenieros QA independientes del equipo de desarrollo. Esta independencia es crucial porque:
- Los desarrolladores tienen sesgo. Conocen como funciona el codigo y inconscientemente prueban el happy path.
- Perspectiva fresca encuentra defectos diferentes. Alguien no familiarizado con la implementacion intentara cosas que el desarrollador nunca considero.
- Enfoque en requisitos. Los ingenieros QA prueban contra requisitos y user stories, no contra codigo.
Diseno de Casos de Prueba de Sistema
Los casos de prueba de sistema se derivan de requisitos, no de codigo. El proceso:
- Analizar requisitos — Leer user stories, criterios de aceptacion y especificaciones
- Identificar condiciones de prueba — Que aspectos de cada requisito necesitan testing?
- Disenar casos de prueba — Que entradas, acciones y resultados verifican cada condicion?
- Priorizar — Que casos cubren mas riesgo?
Ejercicio: Crea Escenarios de Test de Sistema a Partir de Requisitos
Recibes los siguientes requisitos para un sistema de gestion de biblioteca:
REQ-001: Los usuarios registrados pueden buscar libros por titulo, autor o ISBN. REQ-002: Los usuarios pueden reservar libros disponibles por hasta 7 dias. REQ-003: Los usuarios pueden tener maximo 5 reservas activas simultaneamente. REQ-004: Cuando un libro reservado no se recoge en 7 dias, la reserva se cancela automaticamente. REQ-005: Los usuarios con libros vencidos no pueden hacer nuevas reservas hasta devolver los libros.
Crea escenarios de test para REQ-001 a REQ-005. Para cada uno especifica: objetivo, precondiciones, pasos y resultado esperado.
Pista
Para cada requisito, piensa en: el caso normal (happy path), los limites (que pasa en el limite exacto — ej: exactamente 5 reservas), los casos de error (que debe prevenirse) y las interacciones entre requisitos (ej: REQ-003 y REQ-005 interactuan).Solucion
REQ-001: Busqueda de Libros
Test 1: Busqueda por titulo
- Precondicion: La BD contiene “Clean Code” de Robert Martin, ISBN 978-0132350884
- Pasos: Ingresar “Clean Code” en campo de busqueda, seleccionar filtro “Titulo”, click Buscar
- Esperado: “Clean Code” aparece en resultados con autor e ISBN correctos
Test 2: Busqueda parcial
- Precondicion: La BD contiene “Clean Code” y “Clean Architecture”
- Pasos: Buscar “Clean” por titulo
- Esperado: Ambos libros aparecen en resultados
Test 3: Busqueda sin resultados
- Pasos: Buscar “XYZINEXISTENTE” por titulo
- Esperado: Mensaje “No se encontraron resultados”
REQ-002: Reserva de Libros
Test 4: Reservar libro disponible
- Precondicion: Usuario logueado, “Clean Code” muestra “Disponible”
- Pasos: Click “Reservar” en “Clean Code”
- Esperado: Estado cambia a “Reservado”, fecha de expiracion muestra 7 dias desde hoy
Test 5: No se puede reservar libro no disponible
- Precondicion: “Clean Code” reservado por otro usuario
- Esperado: Boton “Reservar” deshabilitado, estado muestra “Reservado”
REQ-003: Maximo 5 Reservas
Test 6: Quinta reserva exitosa
- Precondicion: Usuario tiene 4 reservas activas
- Pasos: Reservar un quinto libro
- Esperado: Reserva exitosa, usuario ahora tiene 5 reservas activas
Test 7: Sexta reserva rechazada
- Precondicion: Usuario tiene 5 reservas activas
- Pasos: Intentar reservar un sexto libro
- Esperado: Error “Maximo de reservas alcanzado (5/5)”
REQ-004: Auto-cancelacion despues de 7 dias
Test 8: Reserva auto-cancelada
- Precondicion: Usuario reservo libro hace 7 dias, no lo recogio
- Pasos: Verificar estado de reserva
- Esperado: Estado “Cancelada - No recogido”, libro disponible nuevamente
REQ-005: Bloqueo por libros vencidos
Test 9: Usuario con libro vencido no puede reservar
- Precondicion: Usuario tiene un libro prestado pasado de fecha
- Pasos: Intentar reservar un nuevo libro
- Esperado: Error “Tienes libros vencidos. Devuelvelos para hacer nuevas reservas.”
Test 10: Bloqueo se levanta al devolver
- Precondicion: Usuario devuelve libro vencido
- Pasos: Intentar reservar nuevo libro
- Esperado: Reserva exitosa
Interaccion entre requisitos (REQ-003 + REQ-005):
Test 11: Usuario con 5 reservas Y libro vencido
- Precondicion: 5 reservas activas, devuelve una pero tiene libro vencido
- Pasos: Intentar reservar tras devolver una reserva
- Esperado: Bloqueado — libro vencido previene reserva sin importar slots disponibles
Estrategias de Ejecucion de Tests de Sistema
Testing Basado en Riesgo
No todos los features tienen el mismo riesgo. Prioriza basado en:
- Impacto de negocio: Features que afectan ingresos, seguridad o cumplimiento
- Complejidad: Features con logica compleja o muchos puntos de integracion
- Frecuencia de cambio: Areas del codigo que cambian frecuentemente
- Historial de defectos: Modulos con bugs previos probablemente tendran mas
Matriz de Trazabilidad
Mapea cada requisito a sus casos de prueba. Esto asegura:
- Ningun requisito queda sin probar
- Ningun caso de prueba existe sin requisito correspondiente
- La cobertura de tests se puede cuantificar para stakeholders
Tips Profesionales
Tip 1: El testing de sistema encuentra bugs diferentes al de integracion. Los tests de integracion detectan incompatibilidades de datos y violaciones de contrato. Los de sistema detectan errores de logica de negocio, problemas de UI/UX y conflictos entre features.
Tip 2: Usa datos similares a produccion. Datos reales sanitizados revelan problemas que los datos sinteticos no detectan — codificacion de caracteres, casos limite en direcciones reales, combinaciones inusuales.
Tip 3: Rastrea cobertura de requisitos, no de codigo. A nivel de sistema, el code coverage no tiene sentido. Lo que importa es si cada requisito fue probado con escenarios positivos, negativos y de frontera.
Conclusiones Clave
- El testing de sistema verifica la aplicacion completa e integrada contra sus requisitos
- Incluye tests funcionales (que hace el sistema) y no funcionales (como se desempena)
- El ambiente de prueba debe replicar produccion para resultados confiables
- Ingenieros QA independientes aportan perspectiva fresca y enfoque en requisitos
- Los casos de prueba se derivan de requisitos usando tecnicas sistematicas de diseno
- La priorizacion basada en riesgo asegura que los features mas criticos se prueben primero