La documentación del entorno de pruebas sirve como el plano técnico para establecer, mantener y gestionar la infraestructura de pruebas. Los entornos de prueba debidamente documentados aseguran condiciones de prueba consistentes, reducen el tiempo de configuración para nuevos miembros del equipo y proporcionan referencia crucial durante incidentes o actualizaciones del entorno. Esta guía integral cubre todos los aspectos de la documentación del entorno de pruebas desde la configuración inicial hasta los procedimientos de mantenimiento continuo.
Comprendiendo la Complejidad del Entorno de Pruebas
Las aplicaciones modernas requieren múltiples entornos de prueba, cada uno sirviendo propósitos específicos en el pipeline de entrega de software. Los entornos de desarrollo proporcionan sandboxes para la codificación inicial y pruebas unitarias. Los entornos de integración validan las interacciones de componentes. Los entornos de staging reflejan la producción lo más fielmente posible. Los entornos de pruebas de rendimiento manejan escenarios de carga y estrés. Cada entorno requiere documentación detallada para asegurar la configuración y utilización adecuadas.
La complejidad se multiplica con arquitecturas de microservicios, despliegues en la nube y modelos de infraestructura híbrida. Las dependencias abarcan bases de datos, colas de mensajes, APIs de terceros, servicios de autenticación y sistemas de monitoreo. Sin documentación exhaustiva, la configuración del entorno se convierte en un cuello de botella, el conocimiento permanece aislado con miembros específicos del equipo, y la resolución de problemas se convierte en largos ejercicios de investigación.
Documentación de Configuración del Entorno
Documento de Especificación de Infraestructura
# Especificación de Infraestructura del Entorno de Pruebas
# Entorno: STAGING
# Última Actualización: Octubre 2025
infraestructura:
proveedor_cloud: AWS
region: us-east-1
zonas_disponibilidad:
- us-east-1a
- us-east-1b
computo:
servidores_web:
tipo: EC2
tipo_instancia: t3.large
cantidad: 2
so: Amazon Linux 2
auto_escalado:
min: 2
max: 6
cpu_objetivo: 70%
servidores_app:
tipo: ECS Fargate
cpu: 2048
memoria: 4096
tareas: 4
imagen_contenedor: app-staging:latest
procesamiento_batch:
tipo: EC2
tipo_instancia: m5.xlarge
cantidad: 1
programacion: "0 2 * * *" # 2 AM diario
almacenamiento:
base_datos:
tipo: RDS PostgreSQL
version: 13.7
clase_instancia: db.r5.large
almacenamiento: 500GB SSD
multi_az: true
retencion_backup: 7 días
almacenamiento_objetos:
tipo: S3
buckets:
- nombre: staging-uploads
versionado: habilitado
ciclo_vida: 90 días
- nombre: staging-reports
encriptacion: AES256
cache:
tipo: ElastiCache Redis
version: 6.2
tipo_nodo: cache.m5.large
nodos: 2
modo_cluster: habilitado
red:
vpc:
cidr: 10.0.0.0/16
subredes:
publicas:
- 10.0.1.0/24
- 10.0.2.0/24
privadas:
- 10.0.10.0/24
- 10.0.11.0/24
balanceador_carga:
tipo: Application Load Balancer
esquema: internet-facing
certificado_ssl: arn:aws:acm:staging-cert
cdn:
proveedor: CloudFront
comportamientos:
- ruta: /api/*
cache: deshabilitado
- ruta: /static/*
cache: 86400 # 24 horas
Configuración de la Aplicación
{
"entorno": "staging",
"aplicacion": {
"nombre": "sistema-gestion-pedidos",
"version": "2.3.1",
"framework": "Spring Boot 2.7",
"version_java": "11",
"herramienta_build": "Maven 3.8"
},
"configuraciones": {
"servidor": {
"puerto": 8080,
"ruta_contexto": "/api",
"timeout_sesion": 1800,
"max_hilos": 200,
"timeout_conexion": 30000
},
"base_datos": {
"url": "jdbc:postgresql://staging-db.aws.com:5432/pedidos",
"tamaño_pool": 20,
"timeout_inactivo": 600000,
"timeout_conexion": 30000,
"umbral_deteccion_fugas": 60000
},
"mensajeria": {
"broker": "rabbitmq://staging-mq.aws.com",
"colas": [
"pedido.creado",
"pedido.procesado",
"inventario.actualizado"
],
"prefetch": 10,
"intentos_reintento": 3
},
"cache": {
"proveedor": "Redis",
"ttl": 3600,
"max_entradas": 10000
},
"logging": {
"nivel": "INFO",
"patron": "%d{ISO8601} [%thread] %-5level %logger{36} - %msg%n",
"archivo": "/var/log/app/application.log",
"tamaño_max": "100MB",
"historial_max": 30
},
"monitoreo": {
"endpoint_metricas": "/actuator/metrics",
"endpoint_salud": "/actuator/health",
"prometheus_habilitado": true,
"metricas_personalizadas": [
"pedido.tiempo.procesamiento",
"pago.tasa.exito"
]
}
}
}
Gestión de Dependencias
Matriz de Dependencias de Servicios
Servicio | Versión | Propósito | Crítico | Estrategia de Respaldo | Equipo Propietario |
---|---|---|---|---|---|
PostgreSQL DB | 13.7 | Almacenamiento primario | Sí | Réplicas de lectura disponibles | Plataforma |
Redis Cache | 6.2 | Caché de sesión y datos | No | Consultas directas a BD | Plataforma |
RabbitMQ | 3.9 | Mensajería asíncrona | Sí | Cola en memoria (degradado) | Plataforma |
Gateway de Pago | API v2 | Procesamiento de pagos | Sí | Reintentar con backoff | Pagos |
Servicio Email | SMTP | Notificaciones | No | Cola para entrega posterior | Comunicaciones |
Gateway SMS | REST v1 | 2FA y alertas | Sí | Respaldo por email | Seguridad |
API Inventario | REST v3 | Verificación de stock | Sí | Datos en caché (obsoletos) | Inventario |
API Envíos | SOAP v2 | Cálculo de tarifas | Sí | Tarifas por defecto | Logística |
Servicio Analytics | gRPC | Seguimiento de uso | No | Logging en archivo local | Analytics |
Servicio Auth | OAuth2 | Autenticación | Sí | Sin respaldo - crítico | Seguridad |
Documentación de Integración con Terceros
# Integración con Servicios de Terceros
## Gateway de Pago (Stripe)
- **Endpoint**: https://api.stripe.com/v1
- **Autenticación**: Bearer token (Clave Secreta)
- **Credenciales de Prueba**:
- Clave Pública: pk_test_51H4kL9...
- Clave Secreta: sk_test_51H4kL9...
- **Tarjetas de Prueba**:
- Éxito: 4242 4242 4242 4242
- Rechazo: 4000 0000 0000 0002
- 3D Secure: 4000 0027 6000 3184
- **Webhooks**:
- URL: https://staging.app.com/webhooks/stripe
- Eventos: payment_intent.succeeded, payment_intent.failed
- **Límites de Tasa**: 100 solicitudes/segundo
- **Monitoreo**: https://dashboard.stripe.com/test/logs
## Servicio de Email (SendGrid)
- **Servidor SMTP**: smtp.sendgrid.net:587
- **Endpoint API**: https://api.sendgrid.com/v3
- **Autenticación**: Clave API
- **Credenciales de Prueba**:
- Clave API: SG.test_key_staging_environment
- **Plantillas**:
- Confirmación de Pedido: d-template-001
- Restablecimiento de Contraseña: d-template-002
- **Límites de Tasa**: 100 emails/segundo
- **Manejo de Rebotes**: Webhook a /webhooks/sendgrid
- **Monitoreo**: https://app.sendgrid.com/statistics
## Gateway SMS (Twilio)
- **Endpoint API**: https://api.twilio.com/2010-04-01
- **SID de Cuenta**: AC_test_staging_account
- **Token de Auth**: auth_token_staging
- **Números de Prueba**:
- Desde: +1234567890
- Números mágicos para pruebas:
- +15005550001: Inválido
- +15005550006: Válido
- **Límites de Tasa**: 1 mensaje/segundo
- **URL de Callback**: https://staging.app.com/webhooks/twilio
Documentación de Gestión de Acceso
Matriz de Acceso al Entorno
# Control de Acceso al Entorno de Pruebas
## Niveles de Acceso
### Nivel 1: Solo Lectura
- Ver logs de aplicación
- Monitorear dashboards
- Consultas de lectura a base de datos
- No puede modificar ningún dato
### Nivel 2: Desarrollador
- Todos los permisos de Nivel 1
- Desplegar código de aplicación
- Modificar configuración de aplicación
- Ejecutar correcciones de datos (con aprobación)
### Nivel 3: Admin
- Todos los permisos de Nivel 2
- Reiniciar servicios
- Modificar infraestructura
- Escrituras directas a base de datos
## Asignaciones de Acceso por Equipo
| Equipo | Entorno | Nivel de Acceso | VPN Requerido | MFA Requerido |
|--------|---------|-----------------|---------------|---------------|
| Desarrollo | DEV | Admin | No | No |
| Desarrollo | INT | Desarrollador | Sí | No |
| Desarrollo | STAGING | Solo Lectura | Sí | Sí |
| QA | DEV | Desarrollador | No | No |
| QA | INT | Admin | Sí | No |
| QA | STAGING | Desarrollador | Sí | Sí |
| DevOps | TODOS | Admin | Sí | Sí |
| Soporte | STAGING | Solo Lectura | Sí | Sí |
| Gerencia | STAGING | Solo Lectura | Sí | Sí |
## Proceso de Solicitud de Acceso
1. Enviar ticket en JIRA (plantilla ENV-ACCESS)
2. Especificar: Entorno, Nivel Requerido, Justificación Empresarial
3. Aprobación del gerente requerida para Nivel 2+
4. Revisión del equipo de seguridad para acceso STAGING
5. Aprovisionamiento automatizado tras aprobación
6. Acceso revisado trimestralmente
7. Revocación automática después de 90 días de inactividad
Gestión de Credenciales
#!/bin/bash
# Script de Rotación de Credenciales
# Ejecutar mensualmente o bajo demanda
# Ubicación de Credenciales del Entorno Staging
# AWS Secrets Manager: arn:aws:secretsmanager:staging-secrets
# Credenciales de Base de Datos
DB_SECRET="staging/rds/postgresql/master"
aws secretsmanager rotate-secret --secret-id $DB_SECRET
# Claves API de Aplicación
declare -a API_KEYS=(
"staging/stripe/api-key"
"staging/sendgrid/api-key"
"staging/twilio/auth-token"
"staging/datadog/api-key"
)
for key in "${API_KEYS[@]}"; do
echo "Rotando: $key"
aws secretsmanager rotate-secret --secret-id $key
sleep 5 # Evitar límite de tasa
done
# Rotación de Claves SSH
ssh-keygen -t rsa -b 4096 -f ~/.ssh/staging_new -N ""
# Desplegar nueva clave pública a servidores
ansible-playbook -i staging rotate-ssh-keys.yml
# Verificación de Renovación de Certificado
openssl x509 -enddate -noout -in /certs/staging.crt
# Auto-renovar si expira dentro de 30 días
echo "Rotación de credenciales completada: $(date)"
Gestión de Datos de Prueba
Procedimientos de Actualización de Datos
-- Procedimiento de Actualización de Datos de Prueba
-- Ejecutar durante ventana de mantenimiento
-- Paso 1: Respaldar datos de prueba actuales
CALL backup_schema('staging_backup_20251008');
-- Paso 2: Sanitizar datos de producción
CREATE TEMP TABLE clientes_sanitizados AS
SELECT
cliente_id,
CONCAT('Test_', SUBSTRING(MD5(email), 1, 8)) as email,
CONCAT('Usuario_', cliente_id) as nombre,
'555-0100' as telefono,
DIGEST(ssn, 'sha256') as ssn_hash,
fecha_creacion,
estado
FROM produccion.clientes
WHERE fecha_creacion > CURRENT_DATE - INTERVAL '90 days'
LIMIT 10000;
-- Paso 3: Enmascarar datos financieros sensibles
UPDATE clientes_sanitizados
SET tarjeta_credito = CONCAT('****-****-****-', RIGHT(tarjeta_credito, 4));
-- Paso 4: Generar transacciones sintéticas
INSERT INTO staging.pedidos (cliente_id, fecha_pedido, total, estado)
SELECT
cliente_id,
CURRENT_DATE - (random() * 30)::int,
(random() * 1000 + 50)::numeric(10,2),
CASE
WHEN random() < 0.7 THEN 'completado'
WHEN random() < 0.9 THEN 'procesando'
ELSE 'cancelado'
END
FROM clientes_sanitizados
CROSS JOIN generate_series(1, 5);
-- Paso 5: Verificar integridad de datos
SELECT
'Clientes' as entidad,
COUNT(*) as conteo_registros,
COUNT(DISTINCT cliente_id) as conteo_unicos
FROM staging.clientes
UNION ALL
SELECT
'Pedidos',
COUNT(*),
COUNT(DISTINCT pedido_id)
FROM staging.pedidos;
Documentación de Conjuntos de Datos de Prueba
# Conjuntos de Datos de Prueba Estándar
conjuntos_datos_prueba:
prueba_humo:
descripcion: "Datos mínimos para pruebas de humo"
clientes: 10
productos: 50
pedidos: 100
tiempo_carga: "< 1 minuto"
prueba_regresion:
descripcion: "Datos completos para pruebas de regresión"
clientes: 1000
productos: 500
pedidos: 10000
meses_historicos: 6
tiempo_carga: "10 minutos"
prueba_rendimiento:
descripcion: "Conjunto de datos grande para pruebas de rendimiento"
clientes: 100000
productos: 10000
pedidos: 1000000
meses_historicos: 12
tiempo_carga: "2 horas"
incluye:
- Escenarios de carga pico
- Simulaciones de usuarios concurrentes
- Procesamiento de lotes grandes
casos_borde:
descripcion: "Escenarios especiales y casos borde"
escenarios:
- Caracteres Unicode en nombres
- Longitudes máximas de campos
- Valores nulos/vacíos
- Caracteres especiales en direcciones
- Límites de zona horaria
- Fechas de año bisiesto
- Límites de precisión de moneda
Monitoreo del Entorno y Verificaciones de Salud
Configuración de Monitoreo
# Configuración de Monitoreo - Entorno Staging
monitoreo:
prometheus:
endpoint: http://prometheus-staging:9090
intervalo_scrape: 30s
retencion: 15d
grafana:
url: https://grafana-staging.internal
dashboards:
- Vista General de Infraestructura
- Métricas de Aplicación
- Rendimiento de Base de Datos
- Tiempos de Respuesta API
alertas:
- nombre: Uso Alto de CPU
condicion: uso_cpu > 80%
duracion: 5m
severidad: advertencia
notificar: [slack, email]
- nombre: Pool de Conexiones DB Agotado
condicion: conexiones_disponibles < 2
duracion: 1m
severidad: critico
notificar: [pagerduty, slack]
- nombre: Degradación Tiempo Respuesta API
condicion: p95_tiempo_respuesta > 3s
duracion: 10m
severidad: advertencia
notificar: [slack]
- nombre: Espacio en Disco Bajo
condicion: disco_usado_porcentaje > 85%
duracion: 5m
severidad: advertencia
notificar: [email]
verificaciones_salud:
aplicacion:
endpoint: /health
intervalo: 30s
timeout: 5s
estado_esperado: 200
base_datos:
consulta: "SELECT 1"
intervalo: 60s
timeout: 3s
cache:
comando: "PING"
intervalo: 30s
respuesta_esperada: "PONG"
servicios_externos:
- nombre: Gateway de Pago
endpoint: https://api.stripe.com/health
intervalo: 5m
- nombre: Servicio Email
endpoint: https://api.sendgrid.com/health
intervalo: 5m
Dashboard de Estado del Entorno
<!DOCTYPE html>
<html>
<head>
<title>Estado del Entorno Staging</title>
<style>
.grid-estado {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
gap: 20px;
padding: 20px;
}
.tarjeta-servicio {
border: 1px solid #ddd;
border-radius: 8px;
padding: 15px;
}
.estado-saludable { color: green; }
.estado-degradado { color: orange; }
.estado-caido { color: red; }
.metrica {
display: flex;
justify-content: space-between;
margin: 5px 0;
}
</style>
</head>
<body>
<h1>Dashboard de Estado del Entorno Staging</h1>
<div class="grid-estado">
<div class="tarjeta-servicio">
<h3>Servidor de Aplicación</h3>
<div class="estado-saludable">● Saludable</div>
<div class="metrica">
<span>Uso de CPU:</span><span>45%</span>
</div>
<div class="metrica">
<span>Memoria:</span><span>2.8/4.0 GB</span>
</div>
<div class="metrica">
<span>Hilos Activos:</span><span>127/200</span>
</div>
<div class="metrica">
<span>Tiempo de Respuesta:</span><span>234ms</span>
</div>
</div>
<div class="tarjeta-servicio">
<h3>Base de Datos</h3>
<div class="estado-saludable">● Saludable</div>
<div class="metrica">
<span>Conexiones:</span><span>15/20</span>
</div>
<div class="metrica">
<span>Tiempo de Consulta:</span><span>12ms prom</span>
</div>
<div class="metrica">
<span>Almacenamiento Usado:</span><span>287/500 GB</span>
</div>
<div class="metrica">
<span>Retraso de Replicación:</span><span>0.3s</span>
</div>
</div>
<div class="tarjeta-servicio">
<h3>Cola de Mensajes</h3>
<div class="estado-degradado">● Degradado</div>
<div class="metrica">
<span>Profundidad de Cola:</span><span>1,247</span>
</div>
<div class="metrica">
<span>Tasa de Procesamiento:</span><span>120/seg</span>
</div>
<div class="metrica">
<span>Tasa de Error:</span><span>0.2%</span>
</div>
<div class="metrica">
<span>Retraso del Consumidor:</span><span>5 min</span>
</div>
</div>
</div>
<script>
// Auto-actualizar cada 30 segundos
setTimeout(() => location.reload(), 30000);
</script>
</body>
</html>
Procedimientos de Despliegue
Lista de Verificación de Despliegue
# Lista de Verificación de Despliegue Staging
## Pre-Despliegue
- [ ] Revisión de código completada y aprobada
- [ ] Todas las pruebas pasando en pipeline CI/CD
- [ ] Migraciones de base de datos revisadas por DBA
- [ ] Escaneo de seguridad completado (sin vulnerabilidades críticas)
- [ ] Impacto en rendimiento evaluado
- [ ] Plan de rollback documentado
- [ ] Stakeholders notificados de ventana de despliegue
## Pasos de Despliegue
1. [ ] Crear respaldo del despliegue actual
```bash
kubectl create backup staging-backup-$(date +%Y%m%d)
Poner aplicación en modo mantenimiento
kubectl annotate deployment app maintenance="true"
Ejecutar migraciones de base de datos
flyway migrate -url=jdbc:postgresql://staging-db/pedidos
Desplegar nueva versión de aplicación
kubectl set image deployment/app app=app:v2.3.1
Verificar estado del despliegue
kubectl rollout status deployment/app
Ejecutar pruebas de humo
npm run test:smoke:staging
Remover modo mantenimiento
kubectl annotate deployment app maintenance-
Post-Despliegue
- Monitorear tasas de error por 30 minutos
- Verificar todos los endpoints de salud
- Verificar flujos críticos de negocio
- Revisar logs de aplicación para errores
- Confirmar métricas de rendimiento aceptables
- Actualizar log de despliegue
- Notificar a stakeholders de completación
Procedimiento de Rollback (si es necesario)
- Identificar el problema que requiere rollback
- Ejecutar rollback:
kubectl rollout undo deployment/app
- Verificar rollback exitoso
- Documentar incidente y causa raíz
- Programar reunión post-mortem
## Guía de Resolución de Problemas
### Problemas Comunes y Soluciones
```markdown
# Guía de Resolución de Problemas del Entorno Staging
## Problemas de Conexión a Base de Datos
### Síntoma: Pool de Conexiones Agotado
**Error**: `HikariPool-1 - Connection is not available, request timed out`
**Verificar**:
```sql
SELECT count(*) FROM pg_stat_activity
WHERE datname = 'pedidos' AND state = 'active';
Resolución:
- Terminar consultas de larga duración:
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE state = 'active' AND query_time > interval '5 minutes';
- Aumentar tamaño del pool en application.yml
- Implementar timeout de conexión
Síntoma: Rendimiento Lento de Consultas
Verificar:
SELECT query, calls, mean_time, max_time
FROM pg_stat_statements
ORDER BY mean_time DESC LIMIT 10;
Resolución:
- Analizar plan de ejecución de consulta
- Agregar índices faltantes
- Actualizar estadísticas de tabla:
ANALYZE nombre_tabla;
- Considerar optimización de consulta
Problemas de Memoria de Aplicación
Síntoma: OutOfMemoryError
Verificar:
jmap -heap <pid>
jstat -gcutil <pid> 1000 10
Resolución:
- Aumentar tamaño del heap:
-Xmx4g
- Analizar dump del heap:
jmap -dump:format=b,file=heap.dump <pid>
- Buscar fugas de memoria usando VisualVM
- Optimizar patrones de creación de objetos
Backlog de Cola de Mensajes
Síntoma: Mensajes No Procesándose
Verificar:
rabbitmqctl list_queues name messages_ready messages_unacknowledged
Resolución:
- Verificar salud del consumidor
- Escalar consumidores
- Purgar cola de mensajes muertos si es necesario
- Implementar patrón circuit breaker
## Programación de Mantenimiento del Entorno
```markdown
# Ventanas de Mantenimiento del Entorno Staging
## Mantenimiento Regular
- **Semanal**: Domingos 2:00 AM - 4:00 AM UTC
- Parches de seguridad
- Rotación de logs
- Limpieza de archivos temporales
- **Mensual**: Primer Domingo 12:00 AM - 6:00 AM UTC
- Actualizaciones del SO
- Mantenimiento de base de datos (VACUUM, ANALYZE)
- Rotación de certificados
- Verificación de respaldo completo
- **Trimestral**: Anunciado con 2 semanas de anticipación
- Actualizaciones mayores de infraestructura
- Actualizaciones de versión de base de datos
- Actualización completa del entorno desde producción
## Mantenimiento de Emergencia
- Comunicado vía canal Slack #staging-status
- Mínimo 2 horas de aviso (excepto seguridad crítica)
- Plan de rollback obligatorio
- Validación post-mantenimiento requerida
## Plantilla de Comunicación de Mantenimiento
Asunto: [STAGING] Mantenimiento Programado - [Fecha]
Duración: [Hora Inicio] - [Hora Fin] UTC
Impacto: Interrupción [Completa/Parcial] esperada
Razón: [Descripción breve]
Contacto: [Ingeniero de guardia]
Actividades:
- [Lista de tareas de mantenimiento]
Pruebas Requeridas Post-Mantenimiento:
- [Casos de prueba específicos a ejecutar]
Conclusión
La documentación exhaustiva del entorno de pruebas transforma la gestión caótica y propensa a errores del entorno en un proceso sistemático y confiable. Esta documentación sirve como la única fuente de verdad para la configuración del entorno, dependencias, procedimientos de acceso y pasos de resolución de problemas. Al mantener documentación detallada del entorno, los equipos reducen el tiempo de configuración, minimizan la deriva de configuración, aceleran la incorporación y mejoran la resolución de incidentes. Recuerde que la documentación del entorno es un artefacto vivo que debe evolucionar con sus cambios de infraestructura y aplicación. Las revisiones regulares, actualizaciones y validación aseguran que la documentación permanezca precisa y valiosa para todos los miembros del equipo.