Datos de prueba en QA: cómo evitar falsos fallos y lograr pruebas reproducibles

Datos de prueba en QA: cómo evitar falsos fallos y lograr pruebas reproducibles

Un endpoint devuelve un error durante una prueba manual, pero al repetir la misma solicitud el resultado cambia. En otra ejecución, un caso que antes fallaba ahora pasa sin modificaciones en el código. Antes de reportar un bug, conviene revisar una causa frecuente: el estado y los datos existentes antes de ejecutar la prueba.

Los datos de prueba no son un detalle secundario. Determinan qué comportamiento puede observarse, qué reglas de negocio se activan y si otra persona podrá reproducir el resultado. En este artículo veremos cómo diseñarlos y controlarlos para reducir falsos fallos en pruebas de API, consultas SQL, automatización y testing manual.

Por qué los datos de prueba afectan el resultado de QA

Una prueba no depende únicamente de los pasos escritos en un caso de prueba. También depende de sus precondiciones: qué usuario existe, qué permisos tiene, qué registros relacionados están disponibles y en qué estado se encuentra el sistema.

Por ejemplo, una prueba que verifica el registro de un cliente puede fallar por motivos diferentes:

• El correo electrónico ya fue utilizado en una ejecución anterior.
• El usuario no tiene el rol necesario para completar la operación.
• Falta un producto activo asociado al pedido.
• El registro existe, pero se encuentra en un estado que la operación no admite.
• Los datos creados por otra prueba modificaron el resultado esperado.

En todos estos casos, el fallo observado puede no representar un defecto del producto. Puede ser una precondición incumplida, un problema de aislamiento o un dato inválido para el escenario.

Fallo del sistema o fallo del escenario

Un bug suele indicar que el sistema no cumple el comportamiento esperado bajo condiciones válidas y conocidas. En cambio, un fallo de datos aparece cuando la prueba no tiene control sobre el contexto en el que se ejecuta.

Esta distinción no significa que el problema de los datos deba ignorarse. Si el equipo no puede preparar o restaurar correctamente el estado necesario, existe un riesgo de calidad en el proceso de pruebas. La evidencia debe permitir distinguir entre ambas situaciones.

Cómo definir precondiciones y estados previos

Una buena prueba describe más que una acción y un resultado. También especifica el estado inicial que debe existir antes de ejecutar la acción.

Una precondición útil debe ser concreta y verificable. En lugar de escribir “existe un usuario válido”, conviene indicar qué significa válido para ese caso:

• El usuario está registrado.
• La cuenta está activa.
• El correo electrónico está confirmado, si la operación lo requiere.
• El usuario posee el rol esperado.
• No tiene una solicitud pendiente que impida crear otra.

El estado previo también puede incluir información relacionada. Para probar la cancelación de una compra, no basta con tener un cliente. El pedido debe existir, pertenecer a ese cliente y encontrarse en un estado que permita cancelarlo.

Ejemplo de precondiciones para una API

Supongamos una operación que permite actualizar el estado de un pedido. El caso de prueba podría documentar lo siguiente:

• Existe un pedido identificado por un valor conocido.
• El pedido pertenece al cliente utilizado en la prueba.
• El estado inicial es “pendiente”.
• El usuario autenticado tiene permisos para modificar pedidos.
• No existe otra operación concurrente modificando ese pedido.

Si la prueba falla, estos datos permiten investigar si el problema está en la transición de estados, en los permisos, en la preparación o en una condición externa.

Diseñar datos válidos, inválidos y de frontera

Un conjunto de pruebas completo no debería contener únicamente datos válidos. También debe representar entradas inválidas y valores cercanos a los límites de las reglas de negocio.

Datos válidos

Representan entradas que el sistema debería aceptar. Deben cumplir las reglas conocidas: formato, obligatoriedad, relaciones entre entidades y restricciones de negocio.

Por ejemplo, para crear una cuenta puede ser necesario utilizar un correo con formato válido, una contraseña que cumpla los requisitos y un identificador que aún no exista.

Datos inválidos

Permiten verificar que el sistema rechaza entradas incorrectas de forma controlada. Algunos ejemplos son:

• Campos obligatorios ausentes.
• Formatos incorrectos.
• Valores fuera del dominio permitido.
• Referencias a entidades inexistentes.
• Usuarios sin permisos suficientes.
• Operaciones incompatibles con el estado actual del recurso.

Un dato inválido debe ser intencional. No conviene que una prueba falle porque el tester desconocía que un registro estaba incompleto o vencido.

Valores límite

Los límites suelen revelar errores que no aparecen con datos comunes. Es útil probar, cuando corresponda, el valor mínimo permitido, el máximo permitido y valores inmediatamente fuera de esos límites.

También deben considerarse fechas, cantidades, longitudes de texto, valores nulos y combinaciones de campos. El límite exacto depende de la regla de negocio y debe quedar documentado para que la prueba sea comprensible.

Unicidad, reutilización y creación de datos

La unicidad es una fuente habitual de resultados inconsistentes. Correos electrónicos, nombres de usuario, números de documento, códigos de cupón y referencias externas suelen tener restricciones únicas.

Reutilizar siempre el mismo dato puede ser conveniente para una prueba de consulta, pero problemático para una prueba de creación. Después de la primera ejecución, el registro ya existe y la segunda ejecución puede fallar correctamente por duplicidad.

Alternativas para controlar la unicidad

• Datos creados por cada ejecución: cada prueba genera identificadores únicos y registra los valores utilizados.
• Datos preexistentes controlados: se mantienen registros conocidos para escenarios de consulta o actualización.
• Preparación y limpieza: se crean los datos antes de la prueba y se eliminan o restauran después.
• Identificadores parametrizados: el caso utiliza un valor variable generado según una convención acordada.

Ninguna alternativa es universal. Crear datos por ejecución mejora el aislamiento, pero puede requerir más preparación. Reutilizar datos simplifica algunos escenarios, aunque aumenta la dependencia del estado compartido. La decisión debe considerar el tipo de prueba, el entorno y las reglas de retención de información.

Ejemplo de consulta para verificar un estado

Una consulta SQL puede ayudar a confirmar una precondición antes de ejecutar una prueba. El nombre de las tablas y columnas depende del sistema, por lo que el ejemplo representa únicamente el concepto:

SELECT id, status
FROM orders
WHERE id = :order_id;

El resultado permite comprobar que el pedido existe y que su estado coincide con el esperado. La consulta no reemplaza la prueba funcional, pero aporta evidencia sobre el contexto en el que se ejecutó.

Cómo lograr aislamiento entre ejecuciones

El aislamiento evita que una prueba dependa accidentalmente de otra. Cuando varias pruebas comparten usuarios, pedidos o configuraciones, una modificación puede alterar el resultado de las siguientes.

En pruebas manuales, el aislamiento puede lograrse utilizando registros identificables y verificando el estado antes de comenzar. En automatización, puede incluir preparación de datos, uso de identificadores únicos y limpieza posterior. En ambos casos, el objetivo es que una ejecución no deje efectos inesperados para la siguiente.

Riesgos de un entorno compartido

• Otra persona cambia el registro mientras se ejecuta el caso.
• Una prueba anterior deja un pedido en un estado diferente.
• Un proceso asíncrono modifica los datos entre pasos.
• La limpieza elimina información que otra prueba necesitaba.
• El entorno contiene datos antiguos cuya procedencia se desconoce.

En sistemas distribuidos también conviene considerar retrasos de propagación. Una creación puede confirmarse en un servicio y tardar un tiempo en estar disponible para otro. Si la prueba consulta inmediatamente sin contemplar ese comportamiento, puede reportar un fallo que en realidad corresponde a una expectativa incorrecta sobre la sincronización.

Limpieza y restauración

La limpieza debe ser específica y segura. Eliminar todos los registros relacionados con una prueba puede afectar a otros escenarios si el entorno es compartido. Por eso es preferible identificar los datos creados por la propia ejecución y actuar únicamente sobre ellos.

En algunos casos no conviene eliminar datos, sino restaurar el estado original. Esto aplica, por ejemplo, cuando se prueba una actualización sobre un registro compartido que debe conservarse para otros casos. La estrategia debe quedar definida antes de ejecutar la prueba.

Registrar los datos como parte de la evidencia de QA

Una evidencia útil no contiene únicamente una captura del mensaje de error. También debe mostrar con qué datos y bajo qué condiciones se obtuvo el resultado.

Según el tipo de prueba, conviene registrar:

• Identificadores de las entidades utilizadas.
• Valores relevantes enviados en la solicitud.
• Estado previo y estado posterior.
• Usuario, rol o permisos utilizados.
• Fecha y entorno de ejecución.
• Resultado recibido y comportamiento esperado.
• Información sobre datos creados, modificados o eliminados.

En una prueba de API, esto puede incluir el método, la ruta, los parámetros relevantes, el cuerpo de la solicitud y la respuesta. No es necesario exponer secretos ni datos personales reales; las credenciales deben protegerse y los datos sensibles deben anonimizarse según las reglas del equipo.

Un registro que facilita la reproducción

Consideremos dos reportes:

• “La actualización del pedido falla con error interno”.
• “El pedido identificado para la prueba se encontraba en estado “entregado”, el usuario tenía rol de operador y se envió una solicitud para cambiarlo a “cancelado”. La API respondió con un error interno, aunque el caso esperaba un rechazo controlado de la transición”.

El segundo reporte ofrece mucho más contexto. Permite revisar la regla de transición, validar si el error es manejado correctamente y repetir el escenario con el mismo estado inicial.

Errores frecuentes al preparar datos de prueba

Asumir que el entorno está limpio

Un entorno de pruebas puede contener información de ejecuciones anteriores, datos de demostración o cambios realizados por otros miembros del equipo. La ausencia de un registro no debería darse por sentada: debe verificarse cuando sea relevante.

Usar datos ambiguos

Valores como “test”, “usuario1” o “pedido temporal” dificultan identificar quién creó el dato y para qué caso se utiliza. Una convención clara, sin incluir información sensible, ayuda a rastrear el propósito de cada registro.

No diferenciar preparación de ejecución

Si el caso de prueba crea el usuario, configura permisos y ejecuta la operación sin documentarlo, será difícil saber qué paso produjo el problema. Separar la preparación de la acción bajo prueba mejora el diagnóstico.

Limpiar demasiado o demasiado poco

Una limpieza insuficiente contamina las siguientes ejecuciones. Una limpieza excesiva puede borrar datos compartidos o dificultar la investigación posterior. El alcance debe ser explícito y compatible con el entorno.

Conservar datos sin considerar privacidad

Los datos de prueba deben evitar información personal real cuando no sea necesaria. Para validar una regla funcional suele bastar con información sintética o anonimizada. La reproducibilidad no justifica exponer datos sensibles.

Una estrategia práctica para comenzar

Un equipo puede mejorar progresivamente su gestión de datos de prueba con un proceso sencillo:

1. Identificar las precondiciones de cada escenario.
2. Separar datos válidos, inválidos y de frontera.
3. Definir qué campos deben ser únicos.
4. Decidir qué datos serán creados, reutilizados o restaurados.
5. Verificar el estado inicial antes de ejecutar la acción.
6. Registrar los identificadores y valores relevantes.
7. Limpiar o restaurar únicamente los datos que correspondan.
8. Documentar las dependencias externas, como procesos asíncronos o permisos.

Este proceso puede aplicarse en una prueba manual con una lista de verificación, en una colección de solicitudes de API o en una suite automatizada. La herramienta cambia, pero el principio permanece: la prueba debe controlar y comunicar el contexto que hace válido su resultado.

Conclusión: una prueba reproducible empieza antes del primer paso

Los datos de prueba determinan qué comportamiento se observa y cuánto valor tiene la evidencia obtenida. Precondiciones claras, datos válidos e inválidos bien definidos, control de unicidad, aislamiento, limpieza y registro del estado permiten diferenciar un defecto real de un problema de preparación.

La próxima vez que un test falle, revisa también qué estado y qué datos existían antes de concluir que encontraste un bug. Esa comprobación puede evitar un falso fallo y, al mismo tiempo, revelar una mejora necesaria en la forma en que el equipo prepara sus pruebas.

Desarrollar esta disciplina es una parte importante de la formación de un QA Tester y complementa el trabajo con SQL, Postman, automatización y testing basado en riesgo.