Un caso de prueba puede estar muy bien diseñado y aun así fallar si los datos o el ambiente no están preparados. Muchas veces una prueba no falla porque la funcionalidad tenga un defecto, sino porque falta un usuario, el producto no tiene stock, el servicio externo no responde o la configuración del ambiente no corresponde.
Por eso, antes de ejecutar pruebas, debemos pensar en dos elementos fundamentales: datos de prueba y ambiente de prueba.
En este tema veremos qué son, por qué importan, cómo prepararlos y qué errores comunes debemos evitar.
Los datos de prueba son los valores, registros, archivos, usuarios, configuraciones o estados que se utilizan para ejecutar una prueba.
Ejemplos:
Los datos condicionan el resultado de la prueba. Si los datos no son los correctos, el resultado puede ser engañoso.
Un ambiente de prueba es el entorno donde se ejecutan las pruebas. Incluye aplicación, base de datos, configuración, servicios, usuarios, versiones, infraestructura y dependencias necesarias.
Un ambiente puede incluir:
Un ambiente mal preparado puede bloquear pruebas o generar defectos falsos.
Los nombres pueden variar entre organizaciones, pero suelen existir ambientes como:
| Ambiente | Uso habitual |
|---|---|
| Local | Usado por desarrolladores en sus máquinas para programar y probar cambios iniciales. |
| Desarrollo | Usado para integrar cambios tempranos y validar funcionalidad en construcción. |
| Testing o QA | Usado por testers para ejecutar pruebas planificadas sobre una versión candidata. |
| Integración | Usado para comprobar comunicación entre sistemas o componentes. |
| Preproducción | Ambiente similar a producción para validaciones finales. |
| Producción | Ambiente real utilizado por usuarios finales. |
Las pruebas deben ejecutarse en el ambiente adecuado según su objetivo y riesgo.
Las precondiciones indican qué debe estar listo antes de ejecutar una prueba. Los datos y el ambiente suelen formar parte de esas precondiciones.
Ejemplo de caso de compra:
Si una de estas condiciones no se cumple, la prueba puede quedar bloqueada o fallar por una causa externa.
Al preparar datos conviene pensar en distintas categorías:
| Tipo de dato | Descripción | Ejemplo |
|---|---|---|
| Válido | Debe ser aceptado por el sistema. | Correo usuario@correo.com. |
| Inválido | Debe ser rechazado o tratado como error. | Correo sin arroba. |
| Límite | Está cerca del borde permitido. | Contraseña de exactamente 8 caracteres si el mínimo es 8. |
| Extremo | Representa valores muy grandes, vacíos o poco frecuentes. | Nombre con 255 caracteres. |
| Especial | Incluye caracteres, formatos o condiciones particulares. | Texto con acentos, espacios o símbolos. |
Una buena selección de datos permite descubrir defectos que no aparecen con datos normales.
Los datos positivos están pensados para que la operación se complete correctamente. Los datos negativos están pensados para comprobar que el sistema rechace o maneje condiciones inválidas.
Ejemplo para registro de usuario:
Ambos son necesarios. Si solo usamos datos positivos, no sabremos si el sistema se protege frente a entradas incorrectas.
Los datos de prueba pueden ser sintéticos o reales.
| Tipo | Ventajas | Riesgos |
|---|---|---|
| Sintéticos | Se crean especialmente para probar; son controlados y evitan exponer información sensible. | Pueden no representar toda la complejidad de datos reales. |
| Reales | Representan situaciones existentes y pueden revelar problemas difíciles de imaginar. | Pueden contener información sensible y requerir anonimización o autorización. |
Como regla general, conviene usar datos sintéticos o anonimizados. Usar datos reales sin control puede generar riesgos legales, de seguridad y privacidad.
Cuando se usan datos basados en información real, es importante proteger datos personales o sensibles. La anonimización consiste en modificar datos para que no identifiquen a personas reales.
Datos sensibles pueden incluir:
Un ambiente de prueba no debe convertirse en una copia insegura de producción. La protección de datos también forma parte de la calidad.
Algunos datos deben permanecer estables para que las pruebas sean repetibles. Otros pueden cambiar naturalmente durante la ejecución.
Ejemplo:
Si una prueba depende de datos que cambian, debemos definir cómo restaurarlos, recrearlos o aislarlos para futuras ejecuciones.
Para que las pruebas sean confiables, muchas veces se necesita preparar datos antes y limpiarlos después.
Preparar datos puede significar:
Limpiar datos puede significar:
Sin limpieza, una ejecución puede afectar a la siguiente y generar resultados impredecibles.
Muchos sistemas dependen de servicios externos: pagos, correo, mensajería, mapas, autenticación, facturación o APIs de terceros. Estas dependencias afectan la preparación del ambiente.
Preguntas importantes:
Cuando una dependencia externa no está controlada, puede volver inestables las pruebas.
Antes de probar, es fundamental saber qué versión está desplegada y con qué configuración. De lo contrario, podríamos reportar defectos sobre una versión incorrecta o comparar resultados con reglas desactualizadas.
Información útil del ambiente:
Esta información también ayuda a reproducir defectos.
Algunas pruebas necesitan un ambiente lo más parecido posible a producción. Esto es especialmente importante para pruebas de sistema, aceptación, rendimiento, despliegue o integraciones críticas.
Un ambiente similar a producción debería parecerse en aspectos como:
Si el ambiente de prueba es demasiado diferente, algunos defectos aparecerán recién en producción.
Para ejecutar un caso de compra exitosa, podríamos preparar:
| Elemento | Preparación necesaria |
|---|---|
| Usuario | Cliente activo con correo verificado y dirección cargada. |
| Producto | Producto publicado con precio definido y stock mayor a cero. |
| Pago | Tarjeta de prueba aprobada en ambiente de sandbox. |
| Correo | Servicio configurado para capturar correos de prueba. |
| Ambiente | Versión candidata desplegada en QA. |
| Limpieza | Cancelar pedido o restaurar stock luego de la prueba si corresponde. |
Esta preparación evita que la prueba falle por causas ajenas al flujo de compra.
Algunos problemas comunes son:
Estos problemas consumen tiempo y pueden confundirse con defectos reales del producto.
Al trabajar con datos y ambientes de prueba, algunos errores frecuentes son:
Una buena preparación reduce bloqueos y mejora la confiabilidad de los resultados.
Para trabajar mejor con datos y ambientes conviene:
El objetivo es que una prueba falle por un defecto real, no por desorden en datos o ambiente.
Los datos y el ambiente son parte esencial del testing. Un caso bien diseñado necesita condiciones adecuadas para ejecutarse. Si los datos son incorrectos o el ambiente está mal configurado, el resultado de la prueba pierde confiabilidad.
Preparar bien significa definir datos, controlar precondiciones, conocer la versión probada, revisar dependencias y mantener el ambiente ordenado. Esto reduce bloqueos, evita falsos defectos y mejora la calidad de la información obtenida.
En el próximo tema estudiaremos una técnica fundamental de diseño de pruebas: clases de equivalencia, que permite seleccionar datos representativos sin probar combinaciones innecesarias.