Shift-Left Testing: Integración Temprana de Calidad para Ahorro de Costos

## Defecto de Lógica de Autenticación

### Escenario 1: Encontrado Durante Revisión de Requisitos (Shift-Left)
- **Descubrimiento**: Analista de negocio nota que requisito de login no especifica timeout de sesión
- **Corrección**: Agregar requisito de timeout a spec (30 minutos)
- **Costo**: 30 minutos × $50/hora = $25
- **Impacto**: Ninguno, requisito aclarado antes de implementación

### Escenario 2: Encontrado Durante Producción (Tradicional)
- **Descubrimiento**: Cliente reporta que permanecen logueados indefinidamente, preocupación de seguridad
- **Investigación**: 4 horas tiempo de desarrollador identificando causa raíz
- **Corrección**: 8 horas implementando gestión de sesiones
- **Testing**: 12 horas pruebas completas de regresión
- **Despliegue**: Release de emergencia, 2 horas coordinación
- **Impacto al cliente**: Exposición de vulnerabilidad de seguridad, clientes molestos
- **Costo**: 26 horas × $75/hora + daño de reputación = $1,950+

**Ahorro con Shift-Left: Reducción de costo 77x**

# Calculadora de costo de defectos basada en fase de descubrimiento

def calcular_costo_defecto(costo_base, fase_descubrimiento):
    """
    Calcular costo de defecto basado en cuándo se descubre

    Args:
        costo_base: Costo si se encuentra durante requisitos (línea base)
        fase_descubrimiento: Fase donde se descubrió el defecto

    Returns:
        Costo total de corregir el defecto
    """
    multiplicadores_costo = {
        'requisitos': 1,
        'diseño': 5,
        'desarrollo': 10,
        'testing': 25,
        'produccion': 100
    }

    multiplicador = multiplicadores_costo.get(fase_descubrimiento, 100)
    costo_total = costo_base * multiplicador

    return {
        'fase': fase_descubrimiento,
        'multiplicador': f"{multiplicador}x",
        'costo_total': costo_total,
        'costo_adicional': costo_total - costo_base
    }

# Ejemplo: Defecto de requisito de seguridad
costo_base = 50  # $50 para corregir durante requisitos

for fase in ['requisitos', 'diseño', 'desarrollo', 'testing', 'produccion']:
    resultado = calcular_costo_defecto(costo_base, fase)
    print(f"{resultado['fase'].capitalize()}: {resultado['multiplicador']} = ${resultado['costo_total']}")

# Salida:
# Requisitos: 1x = $50
# Diseño: 5x = $250
# Desarrollo: 10x = $500
# Testing: 25x = $1250
# Produccion: 100x = $5000

## Revisión de Testabilidad de Requisitos

### Claridad
- [ ] Requisito es inequívoco (solo una interpretación posible)
- [ ] Sin términos vagos como "rápido", "amigable", "aproximadamente"
- [ ] Criterios de aceptación específicos definidos

### Completitud
- [ ] Todas las entradas especificadas
- [ ] Todas las salidas definidas
- [ ] Escenarios de error cubiertos
- [ ] Expectativas de performance establecidas

### Testabilidad
- [ ] Comportamiento observable descrito
- [ ] Criterios de éxito medibles
- [ ] Requisitos de datos de prueba claros
- [ ] Dependencias identificadas

### Consistencia
- [ ] Sin conflictos con otros requisitos
- [ ] Terminología consistente en todo
- [ ] Prioridad alineada con objetivos de negocio

## Mal Requisito (No Testable)
"El sistema debe responder rápidamente a las solicitudes del usuario"

**Problemas:**
- "Rápidamente" es subjetivo e inmedible
- No se identifican solicitudes específicas de usuario
- Sin criterios de aceptación

## Buen Requisito (Testable)
"El sistema debe retornar resultados de búsqueda dentro de 2 segundos para el 95% de consultas
cuando la base de datos contiene hasta 1 millón de productos, medido en el percentil 95
durante carga pico (1000 usuarios concurrentes)"

**Casos de Prueba Derivados:**
1. Búsqueda con 100K productos: tiempo de respuesta < 2s (95% de consultas)
2. Búsqueda con 1M productos: tiempo de respuesta < 2s (95% de consultas)
3. Load test: 1000 usuarios concurrentes, verificar percentil 95 < 2s
4. Caso edge: Búsqueda excediendo 2s debe completarse exitosamente

## Revisión de Testabilidad de Arquitectura

### Modularidad
- [ ] Componentes tienen interfaces bien definidas
- [ ] Dependencias son explícitas y mínimas
- [ ] Cada componente tiene responsabilidad única y clara

### Observabilidad
- [ ] Framework de logging en su lugar
- [ ] Métricas y monitoreo planeados
- [ ] Estados de error visibles y distinguibles

### Controlabilidad
- [ ] Datos de prueba pueden ser inyectados
- [ ] Dependencias externas pueden ser mocked/stubbed
- [ ] Estado puede configurarse programáticamente

### Amigable para Automatización
- [ ] APIs diseñadas para testing automatizado
- [ ] Base de datos accesible para configuración de datos de prueba
- [ ] Configuración puede cambiarse para testing

# Mal Diseño: Difícil de probar
class ProcesadorPagos:
    def procesar_pago(self, monto, numero_tarjeta):
        # Llama directamente a gateway de pagos externo
        respuesta = GatewayPagosExterno.cobrar(monto, numero_tarjeta)

        # Endpoint de producción hardcodeado
        self.enviar_recibo('https://api.produccion.com/enviar-email', respuesta)

        # Sin forma de verificar sin cargos reales
        return respuesta

# Buen Diseño: Testable
class ProcesadorPagos:
    def __init__(self, gateway_pagos, servicio_notificaciones):
        # Inyección de dependencias permite test doubles
        self.gateway_pagos = gateway_pagos
        self.servicio_notificaciones = servicio_notificaciones

    def procesar_pago(self, monto, numero_tarjeta):
        # Usa gateway inyectado (puede ser mocked en pruebas)
        respuesta = self.gateway_pagos.cobrar(monto, numero_tarjeta)

        # Usa servicio de notificaciones inyectado (puede verificar llamadas)
        self.servicio_notificaciones.enviar_recibo(respuesta)

        return respuesta

# Ejemplo de prueba
def test_pago_exitoso():
    # Arrange: Crear test doubles
    mock_gateway = MockGatewayPagos()
    mock_notificaciones = MockServicioNotificaciones()
    procesador = ProcesadorPagos(mock_gateway, mock_notificaciones)

    # Act
    resultado = procesador.procesar_pago(100.00, "4111111111111111")

    # Assert
    assert resultado.exito == True
    assert mock_gateway.cobro_llamado_con(100.00, "4111111111111111")
    assert mock_notificaciones.recibo_enviado == True

# Paso 1: ROJO - Escribir prueba que falla
import pytest

def test_carrito_vacio_tiene_total_cero():
    carrito = CarritoCompras()
    assert carrito.total() == 0

# Ejecutar prueba: FALLA - CarritoCompras no existe aún

# Paso 2: VERDE - Código mínimo para pasar
class CarritoCompras:
    def total(self):
        return 0

# Ejecutar prueba: PASA

# Paso 3: ROJO - Siguiente prueba
def test_carrito_con_un_articulo():
    carrito = CarritoCompras()
    carrito.agregar_articulo(Producto("Libro", 15.99))
    assert carrito.total() == 15.99

# Ejecutar prueba: FALLA - agregar_articulo no existe

# Paso 4: VERDE - Implementar agregar_articulo
class CarritoCompras:
    def __init__(self):
        self.articulos = []

    def agregar_articulo(self, producto):
        self.articulos.append(producto)

    def total(self):
        return sum(item.precio for item in self.articulos)

class Producto:
    def __init__(self, nombre, precio):
        self.nombre = nombre
        self.precio = precio

# Ejecutar pruebas: PASA (ambas pruebas)

# Paso 5: ROJO - Probar con múltiples artículos
def test_carrito_con_multiples_articulos():
    carrito = CarritoCompras()
    carrito.agregar_articulo(Producto("Libro", 15.99))
    carrito.agregar_articulo(Producto("Bolígrafo", 2.50))
    carrito.agregar_articulo(Producto("Cuaderno", 5.99))
    assert carrito.total() == 24.48

# Ejecutar pruebas: PASA (todas las pruebas, no se necesita código nuevo)

# Paso 6: REFACTOR - Extraer lógica de cálculo
class CarritoCompras:
    def __init__(self):
        self.articulos = []

    def agregar_articulo(self, producto):
        self.articulos.append(producto)

    def total(self):
        return self._calcular_total()

    def _calcular_total(self):
        """Calcular suma de todos los precios de artículos"""
        return sum(item.precio for item in self.articulos)

# Ejecutar pruebas: PASA (refactorización preservó comportamiento)

Feature: Login de Usuario
  Como usuario registrado
  Quiero iniciar sesión en mi cuenta
  Para poder acceder a funciones personalizadas

  Scenario: Login exitoso con credenciales válidas
    Given estoy en la página de login
    And tengo una cuenta válida con usuario "juan@ejemplo.com"
    When ingreso usuario "juan@ejemplo.com"
    And ingreso contraseña "ContraseñaSegura123"
    And hago click en el botón "Ingresar"
    Then debo ser redirigido al dashboard
    And debo ver "Bienvenido, Juan"

  Scenario: Login fallido con contraseña incorrecta
    Given estoy en la página de login
    And tengo una cuenta con usuario "juan@ejemplo.com"
    When ingreso usuario "juan@ejemplo.com"
    And ingreso contraseña "ContraseñaIncorrecta"
    And hago click en el botón "Ingresar"
    Then debo permanecer en la página de login
    And debo ver mensaje de error "Usuario o contraseña inválidos"
    And el campo de contraseña debe estar limpio

  Scenario: Bloqueo de cuenta después de múltiples intentos fallidos
    Given estoy en la página de login
    And tengo una cuenta con usuario "juan@ejemplo.com"
    When ingreso usuario "juan@ejemplo.com"
    And ingreso contraseña incorrecta 5 veces
    Then mi cuenta debe estar bloqueada
    And debo ver "Cuenta bloqueada. Por favor reinicia tu contraseña"
    And no debo poder iniciar sesión incluso con contraseña correcta

# features/steps/login_steps.py

from behave import given, when, then

@given('estoy en la página de login')
def step_navegar_a_login(context):
    context.browser.get('https://ejemplo.com/login')

@given('tengo una cuenta válida con usuario "{usuario}"')
def step_crear_usuario_prueba(context, usuario):
    context.usuario_prueba = crear_usuario(usuario, "ContraseñaSegura123")

@when('ingreso usuario "{usuario}"')
def step_ingresar_usuario(context, usuario):
    campo_usuario = context.browser.find_element_by_id('usuario')
    campo_usuario.send_keys(usuario)

@when('ingreso contraseña "{contraseña}"')
def step_ingresar_contraseña(context, contraseña):
    campo_contraseña = context.browser.find_element_by_id('contraseña')
    campo_contraseña.send_keys(contraseña)

@when('hago click en el botón "{texto_boton}"')
def step_click_boton(context, texto_boton):
    boton = context.browser.find_element_by_xpath(f"//button[text()='{texto_boton}']")
    boton.click()

@then('debo ser redirigido al dashboard')
def step_verificar_dashboard(context):
    assert context.browser.current_url == 'https://ejemplo.com/dashboard'

@then('debo ver "{texto}"')
def step_verificar_texto_visible(context, texto):
    assert texto in context.browser.page_source

# Python: Pylint, Flake8, mypy
pylint mi_modulo.py
flake8 mi_modulo.py --max-line-length=100
mypy mi_modulo.py --strict

# JavaScript: ESLint, TSLint
eslint src/**/*.js
tslint src/**/*.ts

# Java: SonarQube, Checkstyle, SpotBugs
sonar-scanner

# Escaneo de seguridad
bandit -r ./src  # Problemas de seguridad Python
npm audit        # Vulnerabilidades de dependencias JavaScript

## Áreas de Enfoque de Revisión de Código

### Funcionalidad
- [ ] Código implementa requisito correctamente
- [ ] Casos edge manejados
- [ ] Manejo de errores implementado
- [ ] Validación de entrada presente

### Testing
- [ ] Pruebas unitarias incluidas
- [ ] Cobertura de pruebas adecuada (>80%)
- [ ] Pruebas verifican casos edge
- [ ] Pruebas de integración para dependencias externas

### Seguridad
- [ ] Sin credenciales hardcodeadas
- [ ] Entrada sanitizada para prevenir inyección
- [ ] Autenticación/autorización aplicada
- [ ] Datos sensibles encriptados

### Performance
- [ ] Sin cuellos de botella obvios de performance
- [ ] Consultas de base de datos optimizadas
- [ ] Caché apropiado usado
- [ ] Limpieza de recursos (conexiones, archivos)

### Mantenibilidad
- [ ] Código es legible y auto-documentado
- [ ] Funciones/métodos tienen responsabilidad única
- [ ] Sin duplicación de código
- [ ] Comentarios explican "por qué" no "qué"

## Evaluación de Preparación Shift-Left

### ¿Cuándo se descubren los defectos?
- [ ] Fase de requisitos: ____%
- [ ] Fase de diseño: ____%
- [ ] Desarrollo: ____%
- [ ] Testing QA: ____%
- [ ] Producción: ____%

**Objetivo: Aumentar descubrimiento en fase temprana (requisitos, diseño, desarrollo)**

### ¿Los testers participan temprano?
- [ ] Revisiones de requisitos: Sí / No
- [ ] Revisiones de diseño: Sí / No
- [ ] Sprint planning: Sí / No
- [ ] Daily standups: Sí / No

**Objetivo: Testers involucrados desde inicio del proyecto**

### ¿Está la automatización en su lugar?
- [ ] Cobertura de pruebas unitarias: ____%
- [ ] Cobertura de pruebas de integración: ____%
- [ ] Pruebas de aceptación automatizadas: Sí / No
- [ ] Pipeline CI/CD: Sí / No

**Objetivo: Alta automatización habilitando testing continuo**

### ¿Nivel de colaboración del equipo?
- [ ] Desarrolladores y testers trabajan en mismo equipo: Sí / No
- [ ] Responsabilidad compartida de calidad: Sí / No
- [ ] Sesiones de compartir conocimiento: Sí / No

**Objetivo: Cultura de equipo colaborativa**

## Fase 1: Acciones Inmediatas (Semana 1-2)

1. **Incluir testers en planificación**
   - Invitar QA a discusiones de requisitos
   - Revisar historias de usuario juntos
   - Definir criterios de aceptación colaborativamente

2. **Implementar checklist de requisitos**
   - Usar checklist de testabilidad para cada requisito
   - Rechazar requisitos poco claros o no testeables
   - Documentar suposiciones explícitamente

3. **Comenzar revisiones de código**
   - Mandar revisión por pares para todo el código
   - Incluir revisión de pruebas en revisión de código
   - Compartir checklist de revisión de código

## Fase 2: Construir Fundación (Mes 1-2)

1. **Introducir TDD para nuevas features**
   - Comenzar con componentes simples
   - Pair programming para aprendizaje de TDD
   - Rastrear métricas de cobertura de pruebas

2. **Automatizar rutas críticas**
   - Identificar top 10 journeys de usuario
   - Escribir pruebas automatizadas para estas rutas
   - Ejecutar en pipeline CI/CD

3. **Proceso de revisión de diseño**
   - Programar revisiones de diseño antes de codificar
   - Usar checklist de testabilidad
   - Involucrar QA en decisiones de arquitectura

## Fase 3: Escalar y Madurar (Mes 3-6)

1. **Expandir adopción de TDD**
   - TDD para todo código nuevo
   - Refactorizar código legacy con pruebas
   - Entrenamiento TDD para todos los desarrolladores

2. **Implementar BDD**
   - Definir escenarios para nuevas features
   - Automatizar escenarios BDD
   - Usar escenarios para validación de requisitos

3. **Mejora continua**
   - Analizar métricas de fase de descubrimiento de defectos
   - Retrospectivas sobre progreso shift-left
   - Ajustar prácticas basado en aprendizajes