Pruebas y calidad en software: que "terminado" signifique "funciona"
"Está terminado" y "funciona" son frases distintas: la demo sale perfecta y la vida real la rompe — el campo vacío, el doble clic, la conexión lenta del local, dos personas guardando a la vez. No necesitas ser ingeniero de calidad para exigir software confiable: necesitas saber qué niveles de prueba existen, cuál te toca a ti y cómo reportar lo que encuentres.
5 de noviembre de 20256 min de lecturaEn este artículo
"Está terminado" y "funciona" son frases distintas, y la diferencia se descubre siempre en el peor momento: la demo salió perfecta, pero el primer día real alguien dejó un campo vacío, otro hizo doble clic en "guardar", la conexión del local estaba lenta y dos personas editaron el mismo pedido a la vez — y el sistema que "estaba terminado" repartió errores toda la mañana.
La calidad del software no es perfección — es confianza ganada a base de pruebas: la certeza razonable de que el sistema aguanta la vida real y no solo la demo. Y aunque las pruebas técnicas son trabajo del desarrollador, hay un nivel que nadie puede hacer por ti y preguntas que te toca exigir. Esta guía te da el mapa completo en cristiano.
Por qué el software "terminado" falla
El desarrollador prueba naturalmente el camino feliz: el flujo donde todo se llena bien, en orden, con buena conexión y de a uno. La vida real es el camino infeliz permanente — datos incompletos, usuarios impacientes, redes lentas, usos simultáneos — y cada combinación no probada es un error esperando su estreno en producción, frente a un cliente. Las pruebas existen para estrenar esos errores en privado, cuando corregirlos es barato, en vez de en público, cuando cuestan ventas y reputación.
Los niveles de prueba, en cristiano
| Nivel | Qué verifica | Quién lo hace |
|---|---|---|
| Pruebas automáticas | Que cada pieza del código haga lo suyo — y lo siga haciendo tras cada cambio | El desarrollador; tú solo confirmas que existen |
| Pruebas funcionales | Que cada historia de los requisitos funcione de punta a punta | El equipo de desarrollo, contra tu documento de requisitos |
| Prueba de aceptación | Que el sistema sirva en TU operación real, con tu gente y tus datos | Tú y tu equipo — nadie puede hacerla por ustedes |
| Pruebas de carga | Que aguante el volumen esperado (usuarios y datos simultáneos) | El desarrollador — relevante si esperas picos o volumen alto |
Tu papel: la prueba de aceptación
Los casos que siempre se olvidan
- La conexión mala: ¿qué pasa con el internet lento o cortado a mitad de un guardado? — el mensaje claro y el dato no perdido separan lo profesional de lo frágil.
- Los extremos de datos: la lista con cero elementos y la lista con diez mil; el nombre de dos letras y el de ochenta — los extremos rompen lo que el promedio perdona.
- La simultaneidad: dos personas editando lo mismo a la vez — ¿quién gana, quién se entera? En sistemas de equipo, esto pasa el primer día.
- El dispositivo real: el celular viejo de tu bodeguero y la tablet barata de la cocina — el software se prueba en los aparatos donde vivirá, no solo en la laptop del desarrollador.
Bugs: cómo reportarlos para que se arreglen rápido
- Los pasos exactos: qué hiciste, en orden, desde dónde — "entré a pedidos, busqué 'García', abrí el segundo resultado, toqué editar".
- Lo esperado vs lo ocurrido: "esperaba ver la ficha; apareció pantalla en blanco" — las dos mitades, siempre.
- La evidencia: captura de pantalla o video corto, más el dispositivo y la hora — la mitad de los bugs "no reproducibles" se resuelven con una buena captura.
- La severidad honesta: distingue "impide operar" de "molesta" y de "detalle" — el proveedor que recibe todo como urgente termina sin priorizar nada.
La calidad después del lanzamiento
Lanzar no termina el tema — lo cambia de fase. Exige tres cosas para la vida en producción: registro de errores (el sistema anota sus propios fallos, con lo que el proveedor arregla causas en vez de adivinar sobre síntomas), un canal y tiempos de soporte acordados (qué es urgente, quién responde, en cuánto) y un período de estabilización presupuestado — las primeras semanas reales siempre revelan ajustes, y saberlo desde el inicio evita que se vivan como fracaso; los plazos completos del proyecto están en cuánto tarda desarrollar una app y el marco general en la guía de crear tu app.
Preguntas frecuentes
¿Cuánto del presupuesto debería ir a pruebas?
En los proyectos serios, las pruebas consumen entre un cuarto y un tercio del esfuerzo total — repartido entre las automáticas que el desarrollador escribe y las rondas funcionales. Si una cotización no menciona pruebas en absoluto, no es más barata: es la misma prueba, pero pagada por tus clientes en producción. La pregunta correcta al cotizar no es "¿cuánto cuestan las pruebas?" sino "¿qué incluye tu proceso de calidad?" — y desconfiar del silencio.
¿El desarrollador no debería entregar sin bugs directamente?
El software sin ningún bug no existe — lo que sí existe y es exigible es la diferencia entre bugs razonables y trabajo descuidado: los flujos principales de los requisitos deben funcionar completos (eso no es negociable), los casos límite pueden tener ajustes pendientes documentados, y los bugs que aparezcan en garantía se corrigen sin costo. Esa palabra — garantía — merece estar en tu contrato: un plazo (60-90 días es común) donde los defectos de lo entregado se arreglan gratis.
¿Qué son las pruebas automatizadas y debo pagar por ellas?
Son código que prueba al código: verificaciones que se ejecutan solas en segundos, cada vez que algo cambia. Su valor no está en el lanzamiento sino en toda la vida posterior: sin ellas, cada cambio futuro puede romper silenciosamente lo que ya funcionaba, y nadie se entera hasta el cliente. No las pagas como extra — vienen dentro del trabajo bien hecho; lo que sí debes hacer es preguntar si existen, porque su ausencia convierte cada mantenimiento futuro en una apuesta.
¿Cuándo está listo para lanzar? Siempre aparece algo más.
Con criterios definidos antes, no con sensaciones al final: las historias del documento de requisitos funcionan todas, la pasada realista con tu equipo corrió días sin bloqueos, los casos olvidados de esta guía se probaron, y los bugs abiertos son solo de la categoría "molesta o detalle" — con fecha de corrección. Esperar el cero absoluto de defectos es no lanzar nunca; lanzar con un bloqueo conocido es incendiar la confianza del equipo. La línea sana está exactamente entre ambos.