Glosario de técnicas de diseño de pruebas

No podés probar infinitos valores de entrada. Pero muchos se comportan igual: si un email con dominio válido funciona, no hace falta probar mil variaciones del mismo tipo. La técnica agrupa las entradas en clases que el sistema trata de la misma forma.

Dividí el dominio de entrada en particiones (clases de equivalencia) válidas e inválidas. Elegí un representante de cada clase y probalo. Un caso por partición cubre toda la clase, sin redundancia.

El email del registro (clases válido / sin dominio / sin arroba), el tipo de archivo del CV (PDF vs todo lo demás) y el orden de fechas de una reserva. En cada caso, un representante de la clase inválida revela validaciones que faltan.

Los bugs viven en los bordes. Los off-by-one (usar < en vez de <=, contar desde 0 o desde 1) son de los errores más comunes y se esconden justo en el límite de un rango.

Para cada rango, probá el valor límite y sus vecinos inmediatos: el mínimo y mínimo-1, el máximo y máximo+1. Si el rango válido es 8 a 64, los casos clave son 7, 8, 64 y 65.

La longitud de la contraseña (64/65/66) y el contador de intentos de login (4 vs 5). También las fechas de reserva (borde de 30 días), la paginación (conteo de páginas y borde de cada página) y el tamaño del CV (límite de 2 MB).

Cuando el resultado depende de la COMBINACIÓN de varias condiciones, probar cada condición por separado no alcanza. Las combinaciones esconden casos que individualmente parecen correctos.

Listá las condiciones, armá una tabla con todas sus combinaciones posibles y definí el resultado esperado de cada fila. Después diseñás un caso de prueba por cada combinación relevante.

La inscripción a cursos combina dos condiciones: prerequisito completado (sí/no) y cupo disponible (sí/no). Cuatro combinaciones, cuatro resultados esperados (inscrito, lista de espera, rechazado). Algunas filas no se respetan, ni en la UI ni en la API.

Un objeto con ciclo de vida (un curso que pasa por inscrito, en progreso, completado…) tiene transiciones permitidas y prohibidas. El error típico: permitir un salto que debería estar prohibido, o no proteger un estado terminal.

Modelá los estados y las transiciones válidas en un diagrama. Después diseñá casos para las transiciones válidas (deben funcionar) Y para las inválidas (deben ser rechazadas). Las inválidas son las que más bugs revelan.

El ciclo de vida del curso: Inscrito → En progreso → Completado → Certificado, con Abandonado como estado terminal. Probá las transiciones prohibidas: ¿podés retomar un curso abandonado? ¿podés certificar dos veces?