Respuesta.

La gestión de datos de prueba es uno de los problemas más antiguos de la automatización. Desde el inicio de la automatización (scripts de prueba en Excel, macros, viejas QTP), los datos a menudo "se almacenaban en la cabeza" del autor de las pruebas o directamente en el código. Con el desarrollo de CI/CD y lanzamientos paralelos, se requieren nuevas estrategias: ¿cómo evitar competiciones cuando varias pruebas utilizan los mismos datos simultáneamente y asegurar la repetibilidad de los resultados?

Problema: los datos de prueba compartidos (shared) rápidamente conducen a colisiones y resultados impredecibles. Las pruebas se vuelven inestables, son difíciles de depurar, y fragmentos de datos "ensucian" las bases, mientras que la ejecución en múltiples hilos provoca errores (data race).

Solución: implementación de estrategias "datos por prueba" (Test Data Per Test):

Uso de datos de prueba únicos o parametrizados para cada prueba
Generación/limpieza de datos antes y después de la prueba (setup/teardown, fixtures)
División de entornos de prueba mediante namespaces, tenants, usuarios
Uso de bases de datos en memoria con reinicialización por prueba

Características clave:

Generación de datos únicos (UUID, timestamp), eliminación automática después de la prueba
Uso de plantillas y fábricas de datos de prueba (Test Data Factories)
Trabajo con entornos sandbox aislados

Preguntas engañosas.

¿Es aceptable usar datos de producción como datos de prueba?

¡No! Es arriesgado para la seguridad, la privacidad, y conduce a resultados impredecibles en las pruebas debido a la variabilidad de los datos.

¿Es suficiente usar setUp y tearDown para limpiar los datos?

No siempre. Ayudan a minimizar riesgos, pero los lanzamientos paralelos pueden chocar las pruebas si los datos permanecen globales o no se vuelven únicos.

¿Se pueden usar los mismos datos de prueba en escenarios de smoke y regresión?

Mejor no. Las pruebas de smoke deben ser lo más independientes posible, mientras que las de regresión requieren una preparación exhaustiva de los datos, de lo contrario, pueden producir falsos positivos.

Errores comunes y anti-patrones

Uso de datos compartidos, "mágicos", que casualmente son adecuados para muchas pruebas
Artefactos de datos no limpiados después de la prueba
Doble uso de los mismos registros en todas las pruebas

Ejemplo de la vida real

Caso negativo

En la empresa había un inicio de sesión común y varios usuarios y pedidos "compartidos", que se utilizaban en todas las pruebas automatizadas. La ejecución paralela provocaba que las pruebas eliminaran pedidos entre sí o cambiaran el estado de un pedido en varios hilos.

Pros:

Rápido y fácil de implementar en una pequeña cantidad de pruebas
No se requiere infraestructura adicional

Contras:

Fallos ambiguos, dificultades con la depuración
Imposible ejecutar pruebas de manera segura en paralelo o en diferentes entornos

Caso positivo

Se implementaron fábricas de datos de prueba: antes de ejecutar la prueba para cada escenario, se creaba un pedido único y un usuario, que se eliminaba al finalizar la prueba, y el entorno sandbox se reinicializaba.