Gestion de Datos de Test

El Problema del Test Data #

Cada test necesita datos — cuentas de usuario, productos, transacciones, configuraciones. De donde vienen estos datos, como se gestionan y como se limpian determina si tu testing es confiable o plagado de resultados impredecibles.

Problemas comunes:

• Conflictos de datos compartidos — dos testers usan la misma cuenta simultaneamente
• Datos obsoletos — test data no coincide con el schema actual
• Violaciones de privacidad — datos reales de clientes en entornos no productivos
• Contaminacion del entorno — datos residuales causan comportamiento inesperado
• Valores hard-coded — test cases se rompen cuando registros especificos cambian

Fuentes de Test Data #

1. Datos Sinteticos (Generados) #

Crear datos artificiales que imitan patrones de produccion sin contener informacion real.

Herramientas: Faker (Python/JS/Ruby), Bogus (.NET), JavaFaker, Mockaroo (web)

from faker import Faker
fake = Faker('es_MX')  # Datos en español latinoamericano

usuario = {
    "nombre": fake.name(),
    "email": fake.email(),
    "telefono": fake.phone_number(),
    "direccion": fake.address(),
    "fecha_nacimiento": fake.date_of_birth(minimum_age=18, maximum_age=80)
}

Pros: Sin preocupaciones de privacidad, volumen ilimitado, reproducible con seeds Contras: Puede no reflejar patrones reales, edge cases pueden perderse

2. Datos de Produccion Enmascarados #

Copiar datos de produccion y reemplazar campos sensibles con valores ficticios preservando relaciones y distribuciones.

Que enmascarar:

• Nombres, emails, telefonos
• Direcciones, direcciones IP
• Numeros de tarjeta, cuentas bancarias
• Numeros de seguro social, identificaciones nacionales
• Registros de salud, datos financieros

Tecnicas de masking:

• Sustitucion — reemplazar nombres reales con ficticios
• Shuffling — reorganizar valores dentro de una columna
• Encriptacion — encriptar campos sensibles
• Nulling — reemplazar con NULL o valores default
• Desplazamiento de fechas — desplazar fechas por un offset aleatorio

Pros: Distribuciones y relaciones realistas, volumenes adecuados Contras: Proceso de masking requiere mantenimiento

3. Data Factories #

Patrones programaticos que crean test data bajo demanda con atributos configurables.

function createUser(overrides = {}) {
  return {
    id: generateUUID(),
    name: faker.name(),
    email: faker.email(),
    role: "user",
    status: "active",
    createdAt: new Date(),
    ...overrides
  };
}

const adminUser = createUser({ role: "admin" });
const inactiveUser = createUser({ status: "inactive" });

Pros: Consistente, auto-documentado, solo crea lo necesario Contras: Requiere esfuerzo de desarrollo, debe mantenerse con cambios de schema

4. Fixtures y Seed Data #

Datasets predefinidos cargados antes de la ejecucion de tests.

Pros: Predecibles, versionados Contras: Pueden volverse obsoletos, dificiles de mantener a escala

Estrategia de Test Data #

Aislamiento de Datos #

Cada test debe crear sus propios datos y no depender de datos creados por otros tests.

Anti-patron: “Ejecuta Test A primero porque Test B necesita la cuenta que Test A crea.”

Mejor practica: Cada test crea los datos en setup, los usa y los limpia en teardown.

Ciclo de Vida de Datos #

Crear → Usar → Verificar → Limpiar

Consideraciones por Entorno #

Ejercicio: Disena una Estrategia de Test Data #

Eres QA Lead para una aplicacion de salud que gestiona registros de pacientes, citas, recetas y reclamos de seguro. Disena una estrategia completa:

1. Que datos generar y que enmascarar de produccion
2. Como manejar requisitos de compliance HIPAA
3. Patrones de data factory para escenarios mas comunes
4. Enfoque de limpieza para entornos de test

createPatient({ age, conditions, insuranceType })
createAppointment({ patient, doctor, type, date })
createPrescription({ patient, medication, dosage })
createClaim({ appointment, amount, status })

Privacidad y Compliance #

Consideraciones GDPR #

• Derecho al olvido aplica incluso a test data si se usaron datos reales
• Minimizacion de datos: Solo crear lo necesario
• Documentar que datos personales existen en entornos de test

PCI DSS para Pagos #

• Nunca usar numeros reales de tarjeta de credito en entornos de test
• Usar numeros de test proporcionados por procesadores de pago

Puntos Clave #

• Nunca usar datos crudos de produccion — anonimizar o generar sinteticos
• Usar data factories para creacion consistente y auto-documentada
• Cada test crea sus datos y limpia despues
• Considerar regulaciones de privacidad (GDPR, HIPAA, PCI DSS)
• Enmascarar datos de produccion por sustitucion, shuffling o encriptacion
• Automatizar limpieza para prevenir contaminacion y tests flaky