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

ServicioVersiónPropósitoCríticoEstrategia de RespaldoEquipo Propietario
PostgreSQL DB13.7Almacenamiento primarioRéplicas de lectura disponiblesPlataforma
Redis Cache6.2Caché de sesión y datosNoConsultas directas a BDPlataforma
RabbitMQ3.9Mensajería asíncronaCola en memoria (degradado)Plataforma
Gateway de PagoAPI v2Procesamiento de pagosReintentar con backoffPagos
Servicio EmailSMTPNotificacionesNoCola para entrega posteriorComunicaciones
Gateway SMSREST v12FA y alertasRespaldo por emailSeguridad
API InventarioREST v3Verificación de stockDatos en caché (obsoletos)Inventario
API EnvíosSOAP v2Cálculo de tarifasTarifas por defectoLogística
Servicio AnalyticsgRPCSeguimiento de usoNoLogging en archivo localAnalytics
Servicio AuthOAuth2AutenticaciónSin respaldo - críticoSeguridad

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)
  1. Poner aplicación en modo mantenimiento

    kubectl annotate deployment app maintenance="true"
    
  2. Ejecutar migraciones de base de datos

    flyway migrate -url=jdbc:postgresql://staging-db/pedidos
    
  3. Desplegar nueva versión de aplicación

    kubectl set image deployment/app app=app:v2.3.1
    
  4. Verificar estado del despliegue

    kubectl rollout status deployment/app
    
  5. Ejecutar pruebas de humo

    npm run test:smoke:staging
    
  6. 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)

  1. Identificar el problema que requiere rollback
  2. Ejecutar rollback:
    kubectl rollout undo deployment/app
    
  3. Verificar rollback exitoso
  4. Documentar incidente y causa raíz
  5. 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:

  1. Terminar consultas de larga duración:
    SELECT pg_terminate_backend(pid)
    FROM pg_stat_activity
    WHERE state = 'active' AND query_time > interval '5 minutes';
    
  2. Aumentar tamaño del pool en application.yml
  3. 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:

  1. Analizar plan de ejecución de consulta
  2. Agregar índices faltantes
  3. Actualizar estadísticas de tabla: ANALYZE nombre_tabla;
  4. 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:

  1. Aumentar tamaño del heap: -Xmx4g
  2. Analizar dump del heap: jmap -dump:format=b,file=heap.dump <pid>
  3. Buscar fugas de memoria usando VisualVM
  4. 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:

  1. Verificar salud del consumidor
  2. Escalar consumidores
  3. Purgar cola de mensajes muertos si es necesario
  4. 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.