Qué es el testing de software: la guía que separa el ruido de la señal

Hay una imagen falsa del testing que persiste: alguien abre la aplicación, hace clic por todos lados y espera a que algo explote. Si nada explota, "está probado". Esa idea es cómoda y es mentira. Probar no es esperar el accidente. Es diseñar un experimento que responda una pregunta concreta y verificable: ¿este software hace lo que prometimos que haría?

El testing de software es el conjunto de actividades que comparan el comportamiento real de un sistema contra el esperado, para descubrir la diferencia antes de que la descubra el usuario. Esa es la definición corta. Lo demás es el mapa de cómo se hace bien y por qué la mayoría lo hace al revés.

Una prueba que nunca podría fallar no está probando nada: solo está confirmando lo que ya creías.

01 · la preguntaQué es una prueba, en serio

Una prueba tiene tres partes, aunque casi nunca las nombramos. Una entrada: el estado y los datos con los que arranca. Una acción: lo que ejecutas. Y, el que se olvida, un oráculo: la regla que decide si el resultado fue correcto. Sin oráculo no hay prueba, hay una demostración.

El oráculo es el corazón del asunto. Cuando alguien dice "ya lo probé y funciona", la pregunta correcta es: ¿funciona comparado con qué? Si no puedes responder eso, no probaste, solo miraste. El temario del ISTQB distingue con cuidado entre un error (la equivocación humana), un defecto (el problema que quedó en el código) y una falla (el síntoma visible cuando el defecto se ejecuta). Probar bien es cazar defectos antes de que sean fallas frente a un cliente.

Y aquí va una verdad que Dijkstra dejó escrita hace medio siglo: probar puede demostrar la presencia de defectos, nunca su ausencia. Ninguna suite garantiza que el software esté libre de errores; lo que te da es evidencia. El objetivo no es la certeza absoluta, que no existe, sino reducir el riesgo a un nivel que puedas defender.

02 · los nivelesDónde se prueba: del ladrillo al edificio

No se prueba todo en el mismo lugar ni de la misma manera. El testing se organiza en niveles, según el tamaño de lo que estás verificando. Entenderlos evita el error más caro de todos: probar la pieza equivocada con la herramienta equivocada.

En la base están las pruebas unitarias: verifican una función o una clase aislada, sin sus vecinos. Son baratas, rápidas y muy específicas. Un poco más arriba, las pruebas de integración comprueban que dos o más piezas se hablan bien entre sí, que es donde suelen esconderse los defectos reales. En la cima, las pruebas end to end recorren un flujo completo como lo haría un usuario, del clic inicial al resultado final.

La regla de bolsillo: cuanto más subes, más realista es la prueba, pero también más lenta y más frágil. Una suite sana tiene muchas pruebas abajo y pocas arriba. La enferma, la que ves en tantos equipos, tiene el reloj de arena invertido: cientos de pruebas end to end lentas y casi ninguna unitaria.

03 · los tiposQué se prueba: no todo es "que funcione"

Los niveles responden dónde. Los tipos responden qué cualidad estás midiendo. Y aquí es donde mucha gente se queda corta, porque cree que probar es solo verificar que el botón hace lo que dice.

La primera gran división es entre pruebas funcionales y no funcionales. Las funcionales preguntan "¿hace lo correcto?": si envío el formulario, ¿se guarda el registro? Las no funcionales preguntan "¿lo hace lo suficientemente bien?": ¿responde rápido, aguanta la carga, es seguro, se puede usar sin manual? El estándar ISO/IEC 25010 pone nombre a estas cualidades y lista ocho características del producto, entre ellas la eficiencia de desempeño, la seguridad, la fiabilidad y la usabilidad. No es un adorno académico: es la lista de todo lo que puede estar bien o mal más allá de "funciona".

De ahí salen familias enteras de pruebas especializadas. Las pruebas de rendimiento miden qué pasa bajo carga y estrés. Las pruebas de regresión vigilan que un cambio nuevo no rompa lo que ya funcionaba. Las pruebas de humo hacen un chequeo rápido de que lo esencial arranca, antes de invertir tiempo en pruebas profundas.

"Funciona" es una respuesta a una sola pregunta. La calidad se juega en las otras siete.

04 · el estiloCómo se prueba: guion contra exploración

Existe una tensión sana entre dos maneras de probar. La primera es scripted: casos escritos de antemano, con pasos y resultado esperado, que se ejecutan igual cada vez. Son ideales para automatizar y para la regresión, porque no dependen de quién los corre.

La segunda son las pruebas exploratorias: el tester aprende, diseña y ejecuta a la vez, siguiendo el olfato hacia donde el sistema huele raro. No reemplazan al guion, lo complementan. El guion encuentra lo que sabías buscar; la exploración, lo que ni se te había ocurrido. Un equipo que solo automatiza se vuelve ciego a lo inesperado, que es justo donde viven los peores defectos.

05 · el límiteCuánto probar: la trampa del cien por ciento

La pregunta que todo equipo se hace tarde o temprano es cuánto es suficiente. La respuesta honesta incomoda: probarlo todo es imposible. El número de estados, entradas y caminos posibles de casi cualquier programa real es tan grande que agotarlos llevaría más tiempo que la vida del producto. Por eso el testing exhaustivo es un mito, no una meta.

Lo que sí puedes hacer es probar con inteligencia. Priorizas por riesgo: dónde una falla dolería más, qué partes cambian más seguido, qué caminos usan más los clientes. Un defecto en el cobro no pesa igual que uno en el color de un ícono. El testing basado en riesgo acepta que los recursos son finitos y los invierte donde más rinden.

También ayuda entender que los defectos se agrupan: una minoría de los módulos concentra la mayoría de los defectos. Si un área ya te dio problemas, probablemente te siga dando, y ahí conviene cavar. El testing no es justo con el código: es despiadado con el riesgo. Y cuidado con la paradoja del pesticida: si corres siempre las mismas pruebas, dejan de encontrar defectos nuevos, igual que un insecticida repetido deja de matar insectos resistentes. Una prueba que lleva un año en verde no siempre es buena noticia: a veces solo dejó de mirar donde ahora está el problema.

06 · el cierreCómo empezar sin ahogarte

Si estás arrancando, no montes el edificio completo el primer día. Empieza por lo que más riesgo reduce con menos esfuerzo: unas cuantas pruebas unitarias sobre la lógica que más te asusta, un puñado de pruebas de humo que confirmen que lo esencial levanta, y exploración manual para los flujos nuevos y frágiles.

Lo que no puede faltar, desde la primera prueba, es el oráculo: la regla clara de qué cuenta como correcto. Todo lo demás (los niveles, los tipos, la automatización) es arquitectura que se construye encima de esa base. Sin ella, por muchas pruebas que tengas, no estás probando: estás decorando.

El testing bien entendido no es un peaje que pagas antes de entregar. Es la forma más barata de aprender la verdad sobre tu software mientras todavía es barato cambiarla: mover el descubrimiento del defecto lo más cerca posible de cuando lo escribiste, y lo más lejos posible de cuando lo sufre un cliente.