Casi todos los cursos de QA enseñan el mismo formato de caso de prueba: ID, precondiciones, pasos, resultado esperado. Lo que casi ninguno enseña es cómo decidir qué probar.
Ese es el hueco real. Puedes tener el formato perfecto y aun así dejar pasar el bug que un usuario encuentra el primer día en producción, simplemente porque tu batería de casos solo cubría el camino feliz.
Aquí no vas a encontrar otra plantilla en blanco, esa ya la tienes en ejemplos reales de QA. Vas a encontrar las técnicas que usa un QA con experiencia para decidir qué casos escribir antes de escribir ninguno.
El error más habitual: probar solo el camino feliz
Un formulario de registro con usuario, contraseña y edad tiene, en teoría, infinitas combinaciones de entrada posibles. Nadie tiene tiempo de probarlas todas, así que la tentación es probar solo las que "deberían" funcionar y dar por hecho el resto.
- Registro con usuario válido
- Login con esas credenciales
- Editar el perfil
- Cerrar sesión
"Por cada camino feliz, al menos dos casos negativos y uno justo en el límite del dato de entrada."
El camino feliz confirma que la funcionalidad existe. No confirma que aguante lo que un usuario real le va a mandar: un campo vacío, un espacio de más, un número negativo, un archivo diez veces más grande de lo esperado. Ahí es donde vive la mayoría de los bugs que llegan a producción.
Las tres técnicas siguientes existen precisamente para eso: convertir un espacio de pruebas infinito en un número de casos manejable, sin dejar fuera los que de verdad importan.
Tres técnicas para no probar a ciegas
Agrupa las entradas posibles en bloques que deberían comportarse igual. Un caso por bloque, no uno por cada valor posible.
Prueba justo en el borde de cada rango, donde el código de comparación falla con más frecuencia.
Cuando el resultado depende de varias condiciones a la vez, mapea cada combinación posible en una tabla.
Partición de equivalencia: agrupar antes de probar
La idea es simple: si un campo de edad acepta usuarios de 18 a 65 años, no hace falta probar cada edad de esa franja. Basta con un valor representativo por cada bloque, porque el sistema debería tratarlos igual.
| Bloque | Rango | Valor representativo |
|---|---|---|
| Inválido (por debajo) | Menos de 18 | 10 |
| Válido | 18 a 65 | 35 |
| Inválido (por encima) | Más de 65 | 90 |
Tres casos en vez de decenas, y con la misma cobertura real. El error habitual es probar 25, 30 y 40 pensando que se está siendo exhaustivo: son tres valores del mismo bloque, así que en la práctica es el mismo caso repetido tres veces.
Valores límite: donde se esconden la mayoría de los bugs reales
Los valores límite se apoyan en la partición de equivalencia pero atacan justo la frontera entre bloques, que es donde el código suele fallar por un operador de comparación mal puesto.
| Regla de negocio | Valor a probar | Qué revela |
|---|---|---|
| Descuento del 10% en compras superiores a 50€ | 49,99€ | Que NO se aplique el descuento |
| Descuento del 10% en compras superiores a 50€ | 50,00€ | Si "superior" incluye o excluye el propio límite |
| Descuento del 10% en compras superiores a 50€ | 50,01€ | Que SÍ se aplique el descuento |
| Subida de archivo, máximo 5 MB | 5.001 KB | Que el sistema rechace el exceso, no que lo trunque |
Ese segundo caso, el valor exacto en el límite, es el que más veces sorprende. Un desarrollador que quería decir "más de 50€" y escribió >= 50 en vez de > 50 produce un bug que solo aparece con ese único valor. Probar 30€ y 80€ nunca lo va a encontrar.
El bug de valor límite más caro que he visto no estaba en un formulario, estaba en la fecha de caducidad de un cupón de descuento: el código comparaba fechas con "menor que" en vez de "menor o igual que", así que el cupón dejaba de funcionar un día antes de lo anunciado. Nadie lo detectó hasta que un cliente escribió quejándose, porque todos los casos de prueba probaban fechas muy dentro o muy fuera del rango válido, nunca la fecha exacta de caducidad.
Tablas de decisión: cuando hay varias condiciones combinadas
Cuando el resultado depende de dos o más condiciones a la vez, listar casos sueltos hace fácil olvidar combinaciones. La tabla de decisión obliga a cubrirlas todas.
| Usuario existe | Contraseña correcta | Cuenta bloqueada | Resultado |
|---|---|---|---|
| Sí | Sí | No | Acceso permitido |
| Sí | Sí | Sí | Bloqueado, aunque la contraseña sea correcta |
| Sí | No | No | Credenciales incorrectas |
| No | – | – | Usuario no encontrado |
La segunda fila es la que más se olvida al escribir casos "a ojo": una cuenta bloqueada con contraseña correcta. Es fácil probar "contraseña correcta funciona" y "cuenta bloqueada no funciona" por separado, y nunca probar juntas ambas condiciones.
Testing exploratorio: lo que ninguna técnica anterior cubre
Las tres técnicas de arriba son sistemáticas, pero ninguna sustituye el rato de usar la aplicación sin guion, con la única intención de romperla. Ese proceso se llama testing exploratorio, y es donde suelen aparecer los bugs más raros: los que dependen de una secuencia de acciones, no de un dato de entrada concreto.
Volver atrás con el botón del navegador a mitad de un pago. Abrir la misma pestaña dos veces y aplicar el mismo cupón en ambas. Dejar un formulario a medias, cambiar de idioma y volver. Ninguna tabla de decisión predice esas combinaciones, pero un usuario real las hace todo el tiempo.
La diferencia entre explorar sin rumbo y testing exploratorio de verdad es tener un objetivo (un "charter"): durante 30 minutos, intentar romper solo el flujo de pago, por ejemplo, en vez de probar la aplicación entera sin foco.
Cómo priorizar: no hay tiempo para probarlo todo
Ninguna técnica resuelve el problema real de un sprint corto: nunca hay tiempo para escribir y ejecutar todos los casos posibles. Priorizar bien importa tanto como diseñar bien.
- Impacto si falla. Un bug en el flujo de pago no es comparable a un bug en un tooltip. Prueba primero lo que más duele si se rompe.
- Frecuencia de uso. La funcionalidad que usa el 90% de los usuarios cada día merece más casos que una opción avanzada que casi nadie toca.
- Código nuevo o muy modificado. El riesgo de bug es mucho más alto en código que acaba de cambiar que en código estable desde hace meses.
- Historial de bugs en esa zona. Si un módulo ya ha dado problemas antes, es más probable que vuelva a darlos que uno que nunca falló.
Con esos cuatro criterios se decide qué se prueba primero cuando el tiempo no llega, y qué casos de menor riesgo pueden quedar para automatizar más adelante en vez de ejecutarse a mano cada sprint. Es justo el punto donde el diseño manual de casos y la automatización se conectan: primero se decide qué probar, después se decide qué de eso merece ejecutarse solo.
La técnica no sustituye al criterio
Ninguna de estas técnicas es una fórmula mágica. La partición de equivalencia depende de que identifiques bien los bloques, la tabla de decisión depende de que no se te escape una condición, y el testing exploratorio depende de conocer el producto lo suficiente como para saber dónde presionar.
Lo honesto es decir que con la práctica se afinan, no se aprenden de memoria en una tarde. La primera vez que diseñes casos con estas técnicas seguramente se te escape algún bloque o alguna combinación, y está bien: es exactamente el tipo de error que un buen proceso de revisión entre compañeros detecta antes de que llegue a producción.
Preguntas frecuentes
¿Qué diferencia hay entre un caso de prueba y un caso de uso?
Un caso de uso describe la interacción completa entre el usuario y el sistema para lograr un objetivo, de forma narrativa. Un caso de prueba es una instrucción concreta y verificable: unos datos de entrada exactos y un resultado esperado exacto, pensada para comprobar una única condición.
¿Qué es la partición de equivalencia y para qué sirve?
Agrupa las posibles entradas en bloques donde, si una falla o funciona, se espera que las demás del mismo bloque se comporten igual. Sirve para no repetir el mismo caso con datos distintos que no aportan cobertura nueva, y así dedicar el tiempo a los bloques que sí importan.
¿Por qué aparecen tantos bugs justo en los valores límite?
Porque el código que compara números casi siempre usa un operador como mayor que o mayor o igual que, y basta con equivocarse en uno para que el límite exacto se comporte distinto de lo esperado. Probar el valor justo en el límite y uno a cada lado detecta ese error con mucha más frecuencia que probar valores centrales del rango.
¿Hace falta escribir casos de prueba manuales si el equipo va a automatizarlos?
Sí. La automatización ejecuta el caso, no lo diseña. Sin decidir antes qué condiciones, límites y combinaciones probar, se automatiza rápido lo que ya se sabía hacer y se sigue sin cubrir lo que de verdad falla. Diseñar el caso es un paso intelectual, independiente de si luego se ejecuta a mano o con Playwright o Cypress.
¿Preguntan por estas técnicas en las entrevistas de QA junior?
Sí. Junto con explicar cómo se escribe un caso de prueba, es una de las preguntas técnicas más repetidas en entrevistas de QA junior en España. Saber nombrar la técnica (partición de equivalencia, valores límite) y explicarla con un ejemplo propio marca la diferencia frente a quien solo describe el formato del documento.
¿Quieres entrar al sector?
Aprende QA desde cero, con formación práctica y orientada al mercado español.