Una prueba útil responde una pregunta concreta. Si cambiamos una tarifa, queremos saber que se calcula como acordamos y que no hemos alterado otros casos. Si conectamos una tienda con un ERP, queremos saber qué ocurre ante un pedido válido, uno repetido y una respuesta que nunca llega.
Hacer testing no equivale a perseguir el mayor número posible de pruebas. Significa obtener evidencia proporcionada al riesgo antes de entregar un cambio y conservar una forma de comprobarlo cuando vuelva a cambiar.
Empezar por el comportamiento, no por la herramienta
Antes de elegir un framework preguntamos qué debe hacer el sistema, qué resultado sería incorrecto y quién sufriría ese error. Una regla que decide un importe merece casos de borde; una pantalla de consulta necesita comprobar que muestra el dato adecuado; un proceso nocturno necesita demostrar que no repite acciones al reanudarse.
Por ejemplo, un presupuesto puede depender de material, medidas y cantidad. No basta con verificar un ejemplo que sale bien. También importan los límites: un tamaño mínimo, una combinación no permitida, una tarifa que dejó de estar vigente y un dato que falta. La elección de casos surge del dominio, no de una lista universal de pruebas.
Cuando los requisitos son ambiguos, escribir una prueba no los aclara por arte de magia. Primero hay que decidir con quien conoce el proceso qué resultado se espera. El análisis de requisitos es el espacio adecuado para resolver esa definición; aquí tratamos cómo comprobarla una vez acordada.
Diferentes niveles responden diferentes preguntas
Una prueba pequeña puede comprobar una regla de cálculo con datos preparados. Es rápida y precisa cuando falla, pero no demuestra que el resto de la aplicación sepa utilizarla. Una prueba de integración verifica que dos componentes colaboran: por ejemplo, que una confirmación guarda el estado correcto y prepara la notificación. Una prueba de recorrido comprueba que una persona puede completar una acción desde la interfaz.
Ningún nivel sustituye automáticamente a los otros. Probar cada cálculo a través del navegador vuelve la comprobación lenta y frágil. Probar únicamente funciones aisladas puede dejar sin descubrir que el formulario envía mal los datos o que una API cambió su contrato. Elegimos una combinación que cubra los riesgos reales y permita interpretar los fallos.
Los límites entre componentes ayudan a decidir qué comprobar por separado y qué contrato verificar entre ellos. La arquitectura de software define esas responsabilidades; aquí elegimos pruebas que aporten evidencia sobre el comportamiento resultante.
Elegir dónde comprobar una regla
Si una regla depende de una entrada y produce un resultado, suele convenir probarla donde pueda observarse sin arrancar sistemas ajenos. Si el riesgo aparece al guardar, cobrar o comunicar ese resultado, necesitamos además verificar esa colaboración. La pregunta no es «¿cuál es el nivel correcto?», sino «¿qué error descubriría esta comprobación y cuál quedaría fuera?».
Casos normales, límites y fallos
El camino feliz demuestra que una operación puede terminar bien. Un producto empresarial también vive de excepciones: un permiso insuficiente, un archivo incompleto, dos solicitudes iguales, un proveedor no disponible o un pedido que cambia de estado mientras se procesa.
No se trata de inventar catástrofes para cada línea. Priorizamos las situaciones que podrían producir datos incoherentes, importes incorrectos, trabajo duplicado o una experiencia difícil de recuperar. Las incidencias reales y las decisiones de negocio ofrecen mejores casos que una lista genérica de escenarios.
Una prueba de error debe comprobar también el estado posterior. Si falla el envío de un correo tras confirmar una compra, necesitamos saber si la compra quedó registrada y si reintentar enviará sólo la comunicación o intentará cobrar otra vez.
Datos de prueba que no oculten el problema
Los datos elegidos condicionan lo que una prueba puede revelar. Si todas las reservas usan la misma fecha y todos los clientes tienen los mismos permisos, es fácil pasar por alto restricciones que aparecen en un caso real. Conviene preparar ejemplos pequeños pero variados, con nombres y expectativas que expliquen por qué existen.
También hay que cuidar la separación respecto a los datos de producción. Copiar información personal a un entorno de pruebas sin necesidad añade riesgo. Cuando hace falta reproducir una incidencia, buscamos el mínimo conjunto de datos y lo tratamos conforme a su sensibilidad.
Una prueba debe poder repetirse. Si sólo pasa cuando se ejecuta después de otra o depende del estado que quedó en un servicio externo, su resultado resulta difícil de interpretar. Aislar datos, controlar el reloj cuando sea relevante y limpiar efectos secundarios suele aportar más confianza que añadir decenas de casos inestables.
Integraciones: distinguir nuestro contrato del proveedor
Una API externa puede fallar, tardar o cambiar una respuesta. Podemos comprobar con un sustituto controlado cómo reacciona nuestro código ante esas situaciones, pero eso no demuestra que el proveedor real responda hoy exactamente igual. Algunas conexiones necesitan además una comprobación contra un entorno de pruebas o una verificación acotada tras publicar.
No conviene usar el proveedor real en todas las pruebas: aumenta coste, lentitud y dependencia de una red que no controlamos. Tampoco conviene simularlo todo y olvidar su contrato. La combinación depende de la integración, de sus límites y del daño de interpretar mal un dato. La construcción de la conexión pertenece al servicio de integración de sistemas; aquí nos centramos en cómo comprobar su comportamiento.
Una prueba que falla debe decir algo útil
Cuando una prueba falla, necesitamos poder identificar qué comportamiento dejó de cumplirse. Si el resultado sólo indica que «algo en la aplicación» ha cambiado, puede requerir demasiado trabajo de investigación. Casos bien nombrados, entradas comprensibles y una expectativa concreta acortan ese tiempo.
También distinguimos entre un fallo del producto y una prueba frágil. Una prueba que depende de un orden casual, de un temporizador arbitrario o del aspecto exacto de un elemento irrelevante puede romperse sin que el usuario haya perdido ninguna función. Ignorar esos fallos de forma sistemática acaba debilitando la confianza en toda la suite.
Cobertura: un mapa incompleto, no una nota
La cobertura de código indica qué partes se ejecutaron durante las pruebas. No demuestra que sus resultados sean correctos ni que se hayan comprobado los límites importantes. Una prueba puede pasar por una función entera sin detectar un cálculo erróneo si nunca afirma cuál debe ser el importe.
La cifra puede ayudar a encontrar zonas sin comprobación y a seguir cambios de una versión a otra. Se vuelve engañosa cuando se usa como único objetivo. Preferimos preguntar qué riesgos quedan descubiertos, qué casos fallaron en producción y qué pruebas habrían permitido detectarlos antes.
Qué cambia al trabajar sobre software heredado
En una aplicación antigua quizá no conozcamos todas las reglas, y algunas conductas históricas pueden resultar extrañas. Antes de reorganizar una parte delicada podemos crear pruebas de caracterización: casos que registran qué hace ahora con entradas representativas. Eso permite comparar después del cambio.
Caracterizar no significa aprobar cualquier resultado. Si encontramos un defecto, decidimos explícitamente si hay que corregirlo, mantener una compatibilidad temporal o migrar datos y consumidores. La auditoría de software y código puede ser necesaria cuando el estado del sistema no permite saber por dónde empezar.
Testing y mantenibilidad se refuerzan
Un sistema con responsabilidades claras facilita preparar casos y entender fallos. Las pruebas, a su vez, reducen incertidumbre al refactorizar o actualizar una dependencia. No sustituyen un diseño comprensible: una red extensa de pruebas que sólo confirma detalles internos puede incluso dificultar una mejora estructural.
La guía de calidad y mantenibilidad del software profundiza en responsabilidades, dependencias, deuda técnica, documentación y continuidad. Esta página mantiene la propiedad de otra pregunta: ¿qué evidencia necesitamos para afirmar que un comportamiento sigue funcionando?
De comprobar a entregar
Que las pruebas pasen en un equipo no garantiza que una versión se haya publicado correctamente. Pueden intervenir configuración, migraciones de datos, cachés o servicios externos. La automatización de despliegues trata cómo ejecutar comprobaciones y entregar cambios de manera repetible. Después de publicar, ciertas operaciones requieren además una verificación real acotada.
No llamamos «probado» a todo el producto porque haya pasado una suite. Es más útil explicar qué se ha comprobado, en qué entorno y qué queda fuera. Así una empresa puede decidir con conocimiento cuándo entregar, qué observar y cómo reaccionar si aparece una incidencia.
Preguntas habituales
¿Necesito pruebas automáticas para cada pantalla?
No necesariamente. Automatizamos aquello cuyo riesgo o repetición lo justifica y elegimos el nivel más estable para comprobarlo. Algunas revisiones visuales y decisiones de uso siguen necesitando observación humana.
¿Un porcentaje alto de cobertura garantiza calidad?
No. Indica ejecución de código, pero no que hayamos elegido expectativas correctas o cubierto los casos de negocio más delicados.
¿Hay que escribir las pruebas antes del código?
Puede ser útil en determinadas reglas y equipos, pero no es un requisito universal. El valor está en aclarar el comportamiento y conservar una forma fiable de comprobarlo.
¿Qué hacemos si las pruebas existentes fallan de forma intermitente?
Investigamos si el producto tiene un problema de concurrencia o si la prueba depende de tiempo, datos u orden no controlados. Tratarla como ruido permanente reduce su valor para detectar fallos reales.
Francisco Javier Bohórquez Ogalla · Desarrollo de software y dirección técnica en dev2bit. Perfil profesional.