Cómo diseñar casos de prueba que encuentren bugs de verdad

La respuesta corta es esta: diseñas casos de prueba que encuentran bugs de verdad cuando dejas de improvisar entradas y aplicas técnicas que cubren el riesgo con pocos casos bien elegidos. Las tres que más rinden son clases de equivalencia, análisis de valores límite y tablas de decisión. No prueban todo, porque probar todo es imposible; prueban lo que importa, y lo hacen de forma que cualquiera puede repetir.

Todo probador choca tarde o temprano con el mismo muro: las combinaciones posibles de un formulario sencillo ya son más de las que podrías ejecutar en toda tu vida. Un campo de edad que acepta números de 0 a 120, otro de país con 200 opciones, un descuento que depende de tres condiciones. Multiplica y te da un número absurdo. Probar caso por caso no es meticulosidad, es rendirse a la fuerza bruta. Y la fuerza bruta se agota antes que los bugs.

01 · el problemaInfinitas pruebas posibles, tiempo finito

El punto de partida del diseño de pruebas es aceptar una verdad incómoda que el ISTQB pone entre sus principios fundamentales: la prueba exhaustiva es imposible, salvo en casos triviales. No puedes ejercitar todas las entradas ni todas las combinaciones. Así que la pregunta útil nunca es "¿cómo pruebo todo?", sino "¿qué subconjunto pequeño de pruebas me da la mayor confianza por el menor esfuerzo?".

Aquí es donde la intuición falla. Un probador con experiencia "huele" dónde hay riesgo, pero esa intuición no se documenta ni se enseña. Las técnicas de diseño hacen lo contrario: convierten ese olfato en un procedimiento. Le das las mismas reglas a dos personas y obtienes casi los mismos casos. Eso es lo que significa reproducible, y es lo que separa una suite profesional de una lista de ocurrencias.

Probar todo es imposible. Elegir bien qué probar es la habilidad entera.

Las técnicas que siguen son de caja negra: diseñas los casos mirando qué debe hacer el sistema, no cómo está escrito por dentro. No necesitas leer el código. Necesitas entender la especificación y saber dónde suelen esconderse los errores.

02 · clases y límitesParticiona el problema y ataca los bordes

La primera técnica es la partición en clases de equivalencia. La idea es simple y poderosa: agrupas las entradas posibles en clases donde el sistema debería comportarse igual, y pruebas un solo representante de cada clase. Si un campo de edad acepta 0 a 120, tienes tres clases evidentes: los valores por debajo (inválidos), los válidos, y los de por encima (inválidos). No hace falta probar 43 y 44 y 45; si el sistema trata bien al 44, tratará bien a todos sus vecinos de clase. Un caso por clase, no cien.

La segunda técnica corrige el punto ciego de la primera. Los bugs no se reparten uniformemente: se concentran en los bordes. Un programador escribe < donde debía escribir <=, y el error solo aparece justo en el límite. Por eso el análisis de valores límite prueba los extremos de cada clase y sus vecinos inmediatos. Para el rango 0 a 120, no pruebas un número cualquiera del medio: pruebas -1, 0 y 1 en el borde inferior, y 119, 120 y 121 en el superior. Ahí es donde el software se rompe.

03 · la lógicaTablas de decisión para reglas de negocio

Clases y límites funcionan de maravilla cuando cada entrada se prueba por su cuenta. Pero mucho software no es así: la salida depende de combinaciones de condiciones. "Si el cliente es premium y el carrito supera 50 euros y es su primera compra, aplica doble descuento." Ahí no basta con probar cada condición aislada, porque el bug vive en la interacción entre ellas.

La técnica correcta es la tabla de decisión. Listas las condiciones de entrada arriba, las acciones o resultados abajo, y cada columna es una combinación posible con su resultado esperado. Con tres condiciones binarias tienes ocho combinaciones; la tabla te obliga a mirarlas todas y a decidir, con la especificación en la mano, qué debería pasar en cada una. Lo revelador es lo que ocurre casi siempre: al llenar la tabla descubres combinaciones que nadie había pensado y para las que la especificación no dice nada. Ese hueco es un bug antes de escribir una sola prueba.

Cuando la explosión de combinaciones es enorme, no las pruebas todas. Ahí entran variantes como la prueba por pares, que reduce cientos de combinaciones a unas pocas decenas sin perder casi cobertura de defectos. El principio es el mismo de todo el artículo: no cubrir cada combinación, sino cubrir el riesgo con el mínimo de casos.

La tabla no solo genera casos: te muestra las reglas que nadie escribió.

04 · el criterioCuándo usar cada técnica y cómo documentarla

Ninguna técnica es la buena en abstracto; cada una responde a una forma de riesgo. La guía práctica es esta: si el campo tiene rangos o conjuntos de valores, usa clases de equivalencia con valores límite. Si el resultado depende de la combinación de varias condiciones, usa tabla de decisión. Si el comportamiento depende del orden de las cosas o del estado del sistema, te falta una cuarta técnica, la transición de estados, que merece su propio artículo.

Y hay una regla que las envuelve a todas: un caso de prueba sin resultado esperado definido de antemano no es un caso de prueba, es una exploración. La potencia de estas técnicas es que el resultado esperado sale de la especificación, no de mirar lo que el sistema hizo y darlo por bueno. Sin ese oráculo previo, no estás probando: estás confirmando tu propio sesgo.

Todo esto conecta con algo más grande que la caza de bugs. La norma ISO/IEC 25010 define la calidad del software en atributos como la corrección funcional, y las técnicas de diseño de casos son, literalmente, la manera de evidenciar que ese atributo se cumple. No es burocracia: es la diferencia entre afirmar "esto funciona" y poder mostrar con qué casos, elegidos con qué criterio, lo comprobaste. El ISTQB coloca estas técnicas en el centro de la formación de un probador precisamente por eso: son el puente entre la intuición y el método.

Así que la próxima vez que sientas el vértigo de las infinitas pruebas posibles, no empieces a teclear entradas al azar. Pregunta primero: ¿esto son rangos, combinaciones o estados? La respuesta te dice qué técnica sacar de la caja, y de golpe el problema deja de ser infinito y pasa a ser una lista corta, ordenada y, sobre todo, repetible.