Las Tres Categorias
Toda feature necesita test cases en tres categorias: tests positivos que confirman que el happy path funciona, tests negativos que verifican el manejo de errores, y tests de frontera que revisan valores limite. Omitir cualquier categoria deja brechas peligrosas.
Test Cases Positivos
Los test cases positivos verifican que el sistema funciona correctamente con input valido bajo condiciones esperadas. Representan los caminos que la mayoria de usuarios seguira.
Caracteristicas:
- Usan valores de input validos y esperados
- Siguen el flujo de trabajo previsto
- Verifican resultados exitosos
- Responden: “Funciona la feature como fue disenada?”
Ejemplo — Formulario de login:
Positivo TC-1: Usuario hace login con email y password validos
Positivo TC-2: Usuario hace login con username y password validos
Positivo TC-3: Usuario hace login y "Remember Me" mantiene sesion por 30 dias
Ejemplo — Carrito de compras:
Positivo TC-1: Agregar un producto al carrito vacio
Positivo TC-2: Agregar multiples cantidades del mismo producto
Positivo TC-3: Actualizar cantidad de 1 a 5
Positivo TC-4: Aplicar cupon valido y verificar descuento
Test Cases Negativos
Los test cases negativos verifican que el sistema maneja input invalido elegantemente — mostrando mensajes de error apropiados, sin caerse y sin exponer datos sensibles.
Caracteristicas:
- Usan input invalido, inesperado o malicioso
- Prueban manejo de errores y validacion
- Verifican mensajes de error apropiados
- Responden: “Falla la feature de forma segura?”
Ejemplo — Formulario de login:
Negativo TC-1: Login con password incorrecto — mensaje de error mostrado
Negativo TC-2: Login con email inexistente — error generico (sin fuga de informacion)
Negativo TC-3: Login con campos vacios — error de validacion
Negativo TC-4: Login con SQL injection en campo de email — input sanitizado
Negativo TC-5: Enviar formulario con payload XSS en email — input escapado
Ejemplo — Carrito de compras:
Negativo TC-1: Agregar producto con cantidad 0 — error de validacion
Negativo TC-2: Agregar producto con cantidad negativa — error de validacion
Negativo TC-3: Aplicar cupon expirado — error: "Coupon has expired"
Negativo TC-4: Agregar producto sin stock — mensaje apropiado
Negativo TC-5: Aplicar cupon con carrito bajo minimo — mensaje de error
Test Cases de Frontera
Los test cases de frontera apuntan a los bordes exactos de rangos de input validos. La mayoria de bugs viven en los limites.
La regla de boundary values: Para un rango [min, max], probar:
- Un valor debajo del minimo (min - 1)
- Valor minimo (min)
- Un valor arriba del minimo (min + 1)
- Un valor debajo del maximo (max - 1)
- Valor maximo (max)
- Un valor arriba del maximo (max + 1)
Ejemplo — Campo de edad (acepta 18-65):
| Valor | Categoria | Resultado Esperado |
|---|---|---|
| 17 | Debajo del limite | Rechazado: “Must be at least 18” |
| 18 | Limite inferior | Aceptado |
| 19 | Justo arriba del inferior | Aceptado |
| 64 | Justo debajo del superior | Aceptado |
| 65 | Limite superior | Aceptado |
| 66 | Arriba del limite | Rechazado: “Must be 65 or under” |
Ejemplo — Campo de password (8-64 caracteres):
| Valor | Categoria | Resultado Esperado |
|---|---|---|
| 7 chars | Debajo del minimo | Rechazado: “Minimum 8 characters” |
| 8 chars | Limite minimo | Aceptado |
| 9 chars | Justo arriba del minimo | Aceptado |
| 63 chars | Justo debajo del maximo | Aceptado |
| 64 chars | Limite maximo | Aceptado |
| 65 chars | Arriba del maximo | Rechazado: “Maximum 64 characters” |
Tipos Comunes de Boundary
Longitud de Strings
Probar string vacio, 1 caracter, longitud minima, longitud maxima, maximo + 1.
Rangos Numericos
Probar minimo - 1, minimo, maximo, maximo + 1, cero, numeros negativos.
Campos de Fecha
Probar ayer vs hoy (para fechas futuras), fin de mes, ano bisiesto (29 Feb), limites de ano.
Colecciones/Listas
Probar lista vacia, un item, items maximos, maximo + 1 items.
Carga de Archivos
Probar archivo vacio, tamano minimo, tamano maximo, maximo + 1 byte.
Disenando Cobertura Completa
Para cualquier feature, usa este enfoque sistematico:
- Identificar todos los campos de input y sus rangos validos
- Escribir cases positivos para los escenarios validos mas comunes
- Escribir cases de frontera para valores min y max de cada input
- Escribir cases negativos para cada tipo de input invalido
- Agregar cases especiales para null, vacio, caracteres especiales, Unicode
Ejercicio: Disena una Suite de Tests Completa
Disena test cases positivos, negativos y de frontera para un formulario de registro con estos campos:
- Username: 3-20 caracteres alfanumericos, debe ser unico
- Email: Formato email valido, debe ser unico
- Password: 8-128 caracteres, debe contener mayuscula, minuscula, digito, caracter especial
- Edad: 13-120, solo enteros
- Bio de perfil: Opcional, max 500 caracteres
Escribe al menos 5 positivos, 8 negativos y 6 de frontera.
Solucion
Test Cases Positivos:
- Registrar con username valido (8 chars), email valido, password fuerte, edad 25, sin bio
- Registrar con username minimo (3 chars), email valido, password con todos los tipos requeridos, edad 30, bio de 100 chars
- Registrar con username maximo (20 chars), email valido, password largo (50 chars), edad 45, bio completa de 500 chars
- Registrar con username alfanumerico con digitos, direccion Gmail, password con caracteres especiales (!@#), edad 18, bio vacia
- Registrar con datos validos y verificar email de confirmacion recibido
Test Cases Negativos:
- Registrar con username ya tomado — error: “Username already exists”
- Registrar con email ya registrado — error: “Email already registered”
- Registrar con formato de email invalido (sin @) — error de validacion
- Registrar con password sin mayuscula — error: “Must contain uppercase letter”
- Registrar con password sin digito — error: “Must contain a digit”
- Registrar con password sin caracter especial — error especificando requisito
- Registrar con edad no entera (25.5) — error de validacion
- Registrar con campos requeridos vacios — cada uno muestra “This field is required”
Test Cases de Frontera:
- Username con 2 caracteres (debajo del min) — rechazado
- Username con 3 caracteres (minimo) — aceptado
- Username con 20 caracteres (maximo) — aceptado
- Username con 21 caracteres (arriba del max) — rechazado
- Edad 12 (debajo del minimo) — rechazado
- Edad 13 (minimo) — aceptado
- Edad 120 (maximo) — aceptado
- Edad 121 (arriba del maximo) — rechazado
- Password con 7 caracteres — rechazado
- Password con 8 caracteres (todos los requisitos) — aceptado
- Bio con 500 caracteres — aceptado
- Bio con 501 caracteres — rechazado o truncado
Pro Tips
Tip 1: La regla 80/20 aplica — 80% de bugs se encuentran en boundaries y escenarios negativos, no en happy paths.
Tip 2: Por cada test case positivo, pregunta “Que podria salir mal?” para generar cases negativos.
Tip 3: Considera combinaciones — que pasa cuando dos boundary values se ingresan simultaneamente?
Tip 4: No olvides valores null y vacios — son los boundary cases mas olvidados y fuente de NullPointerExceptions en produccion.
Puntos Clave
- Tres categorias: positivo (input valido, happy path), negativo (input invalido, manejo de errores), frontera (valores limite)
- Boundary testing revisa min, max, y un paso mas alla de cada borde
- La mayoria de bugs viven en los limites — invierte tu tiempo de testing ahi
- Para cada campo: debajo del min, min, min+1, max-1, max, arriba del max
- Testing negativo protege contra crashes, exposicion de datos y mala experiencia de usuario
- Combina categorias para cobertura completa en cada feature