Diseñar Pruebas que Detectan Errores de Verdad. Cómo elegir bien qué probar en una aplicación web real
En desarrollo web no se prueba para “cumplir”, se prueba para reducir riesgo. Una aplicación web puede funcionar bien en apariencia y, aun así, fallar en situaciones concretas: ciertos datos, combinaciones de permisos o estados poco frecuentes. El diseño de pruebas existe para atacar ese problema de forma inteligente.
Como no es posible probar todas las combinaciones posibles, el objetivo es elegir los casos que tienen más probabilidad de romper el sistema. Esto permite detectar errores graves con menos esfuerzo y enfocar las pruebas donde realmente aportan valor en una aplicación web real.
Diseñar pruebas es como revisar un ascensor antes de abrir un edificio. No pruebas cada peso posible ni cada persona del mundo. Pruebas vacío, carga normal y carga máxima. Revisas puertas, botones y emergencias. Si esos puntos críticos funcionan, el riesgo real baja drásticamente.
Diseño de pruebas: elegir bien qué casos probar
El diseño de pruebas resuelve una limitación básica: no se puede probar todo. En lugar de probar valores al azar, se usan técnicas para seleccionar entradas representativas que se comportan de forma similar. Esto reduce trabajo y aumenta la probabilidad de encontrar errores reales.
1. Partición de Equivalencia
La partición de equivalencia consiste en agrupar datos que deberían producir el mismo resultado. Por ejemplo, si una edad válida va de 18 a 65, todas las edades dentro de ese rango se consideran equivalentes. Probar una sola edad representativa suele ser suficiente para esa clase de datos.
La Partición de Equivalencia es una técnica de testing que agrupa los datos de entrada en clases donde todos los valores dentro de una misma clase deberían ser procesados de manera idéntica por el sistema.
Filosofía clave:
- "Si un valor funciona, todos los valores similares deberían funcionar"
- En lugar de probar todos los valores posibles (imposible), probamos representantes de cada grupo
Proceso en 3 pasos:
1. Identificar rangos de entrada
Para cada campo/entrada, identificar qué valores son válidos e inválidos
2. Crear clases de equivalencia
Ejemplo: Campo "edad" (18-65 años)
- Clase válida 1: 18-65 (incluyendo límites)
- Clase inválida 1: <18 (edad muy baja)
- Clase inválida 2: >65 (edad muy alta)
3. Seleccionar valores de prueba
De cada clase, elegir UN valor representativo:
- Clase válida: 30 (cualquier edad entre 18-65)
- Clase inválida baja: 17
- Clase inválida alta: 66
Ejemplos prácticos:
Cantidad de productos:
// Rango válido: 1-100 unidades
Clases de equivalencia:
- Válida: 1-100 → Probar con: 50
- Inválida baja: ≤0 → Probar con: 0
- Inválida alta: >100 → Probar con: 101
Campo email:
Clases de equivalencia:
- Válida: email con formato correcto → "usuario@dominio.com"
- Inválida 1: sin @ → "usuariodominio.com"
- Inválida 2: sin dominio → "usuario@"
- Inválida 3: vacío → ""
Número de tarjeta de crédito:
// Longitud válida: 16 dígitos
Clases de equivalencia:
- Válida: 16 dígitos → "4111111111111111"
- Inválida corta: <16 dígitos → "411111111111"
- Inválida larga: >16 dígitos → "41111111111111111"
Beneficios principales:
| Beneficio | Descripción |
|---|---|
| Eficiencia | Reduce drásticamente el número de pruebas necesarias |
| Cobertura | Asegura que todas las clases de datos sean probadas |
| Detección temprana | Identifica clases de equivalencia no consideradas |
| Mantenimiento | Fácil de actualizar cuando cambian los requisitos |
Relación con Análisis de Valores Límite:
En resumen: La Partición de Equivalencia es una técnica inteligente y eficiente que permite obtener máxima cobertura de testing con mínimo esfuerzo, basándose en el principio de que dentro de cada "categoría" de datos, el sistema se comporta de manera consistente.
2. Análisis de Valores Límite (Boundary Value Analysis)
El análisis de valores límite se centra en los bordes, porque ahí fallan muchos sistemas. Justo antes del mínimo permitido, en el valor mínimo, en el máximo y justo después. En una aplicación web, estos errores aparecen con límites de cantidad, fechas, precios o tamaños de texto.
El Análisis de Valores Límite es una técnica de testing que se enfoca específicamente en los extremos o límites de los rangos válidos, porque es donde ocurren la mayoría de los errores en los sistemas.
¿Por qué en los bordes?
- Los desarrolladores suelen programar condiciones como
>=,<=,>,< - Un error común es usar
>en lugar de>=o viceversa - Los "casos límite" son propensos a errores de lógica
Estrategia de prueba típica:
Para un rango válido de 1 a 100, se prueban:
- 0 - Justo antes del mínimo (debería fallar)
- 1 - Valor mínimo exacto (debería funcionar)
- 100 - Valor máximo exacto (debería funcionar)
- 101 - Justo después del máximo (debería fallar)
Ejemplos prácticos en aplicaciones web:
Cantidades:
// Campo: Cantidad de productos (1-99 unidades)
Valores a probar: 0, 1, 99, 100
Fechas:
// Campo: Fecha de nacimiento (mayores de 18 años)
// Fecha límite: 1 de Enero de 2006 para 2024
Valores a probar:
- 31/12/2005 (17 años, 364 días) ❌
- 01/01/2006 (18 años exactos) ✅
Precios:
// Campo: Descuento (0-50% de descuento)
Valores a probar: -1%, 0%, 50%, 51%
Tamaños de texto:
// Campo: Nombre (3-50 caracteres)
Valores a probar:
- 2 caracteres: "Ab" ❌
- 3 caracteres: "Ana" ✅
- 50 caracteres: (texto de 50 chars) ✅
- 51 caracteres: (texto de 51 chars) ❌
Beneficios clave:
- Eficiencia - Pocos casos cubren muchos errores potenciales
- Efectividad - Detecta errores comunes de lógica
- Sistemático - Método estructurado y repetible
Caso de error típico detectado:
// Error común en código:
if (value > 0 && value < 100) {
// Acepta valores 1-99, pero debería aceptar 100 también
// ¡Falta el = en la segunda condición!
}
// Lo correcto sería:
if (value >= 0 && value <= 100) {
// Acepta correctamente 0-100
}
En resumen: Esta técnica es fundamental para probar sistemas robustos, ya que identifica errores en los puntos más críticos donde la lógica de validación cambia de estado (válido/inválido).
3. Tablas de Decisión
Las tablas de decisión se usan cuando hay varias condiciones combinadas: roles de usuario, permisos, estados y flags. En lugar de improvisar, se listan combinaciones relevantes para no olvidar casos críticos. Esto es habitual en sistemas con autorización, flujos de pedidos o reglas de negocio complejas.
Las tablas de decisión son una herramienta sistemática para manejar situaciones donde múltiples condiciones se combinan de manera compleja.
¿Para qué sirven?
- Evitar la improvisación - Proporcionan estructura frente a la complejidad
- Garantizar cobertura completa - Aseguran que no se olviden casos importantes
- Documentar lógica - Crean un registro claro de las combinaciones válidas
Aplicaciones típicas:
- Sistemas de autorización (quién puede hacer qué)
- Flujos de procesos (estados de pedidos, aprobaciones)
- Reglas de negocio (criterios complejos de decisión)
Elementos que manejan:
- Roles: Tipos de usuarios (admin, cliente, empleado)
- Permisos: Acciones permitidas (leer, escribir, eliminar)
- Estados: Situaciones del sistema (pendiente, aprobado, rechazado)
- Flags/Indicadores: Condiciones booleanas (esVIP, tieneDescuento, urgente)
Ejemplo visual de tabla de decisión:
| Rol | Permiso | Estado Pedido | Es VIP | Acción Permitida |
|---|---|---|---|---|
| Cliente | Editar | Pendiente | Sí | ✅ Permitido |
| Cliente | Editar | Pendiente | No | ✅ Permitido |
| Cliente | Editar | Aprobado | Sí/No | ❌ Denegado |
| Admin | Editar | Cualquiera | Sí/No | ✅ Permitido |
| Empleado | Editar | Pendiente | Sí/No | ✅ Permitido |
Dónde se aplica el diseño de pruebas en una web
En una aplicación web real, estas técnicas se aplican continuamente. Validaciones de formularios, reglas de negocio, permisos por rol, límites de capacidad, estados de pedidos y cualquier lógica con condiciones encadenadas se benefician directamente de un buen diseño de pruebas.
Una analogía clara es un videojuego con misiones desbloqueables. No pruebas cada segundo del juego, pruebas misiones clave: inicio, cambio de nivel, derrota y victoria. Si esos puntos funcionan, el juego es estable. En una web ocurre lo mismo con los flujos críticos.