Probamos software porque las aplicaciones forman parte de actividades reales: comprar, vender, estudiar, comunicarse, administrar datos, reservar turnos, pagar servicios, controlar procesos o tomar decisiones. Cuando un sistema falla, el problema no queda limitado al código; puede afectar a personas, dinero, tiempo, reputación y confianza.
El testing ayuda a descubrir defectos antes de que generen consecuencias importantes. También aporta información para decidir si una versión está lista, si necesita más correcciones o si conviene asumir ciertos riesgos de manera consciente.
En este tema veremos tres ideas centrales: calidad, riesgo y confianza. Estas ideas explican por qué el testing es una actividad necesaria en proyectos pequeños, medianos y grandes.
La calidad de software no significa solamente que un programa "funcione". Un sistema puede ejecutar una operación y, aun así, tener problemas de calidad: puede ser lento, confuso, inseguro, difícil de mantener o fallar con datos no previstos.
Cuando probamos, observamos distintos aspectos del producto:
El testing no crea calidad por sí solo, pero ayuda a revelar problemas que impiden alcanzarla. Cuando esos problemas se corrigen, el producto mejora.
Un riesgo es la posibilidad de que ocurra un problema y genere un impacto negativo. En software, el riesgo aparece cuando una falla puede producir consecuencias importantes.
Por ejemplo, no tiene el mismo impacto un error de color en un botón que un error en el cálculo del total de una factura. Ambos pueden ser defectos, pero el riesgo asociado es diferente.
El testing ayuda a reducir riesgos porque permite encontrar problemas antes de publicar el sistema. También ayuda a identificar qué partes deben probarse con mayor profundidad.
Los riesgos dependen del tipo de aplicación. Algunos ejemplos comunes son:
Un buen proceso de testing no trata todos los riesgos como iguales. Prioriza lo más importante, lo más usado, lo más reciente y lo que tendría mayor impacto si falla.
Antes de entregar una versión, el equipo necesita confianza. No una confianza basada en suposiciones, sino en evidencia. El testing aporta esa evidencia mediante casos ejecutados, defectos encontrados, resultados registrados y riesgos conocidos.
La confianza no significa certeza absoluta. Significa que, con la información disponible, el equipo puede tomar una decisión razonable. Por ejemplo:
En este sentido, el testing no solo encuentra errores: ayuda a decidir.
Un defecto encontrado temprano suele ser más barato de corregir que un defecto encontrado tarde. Si un requisito está mal entendido y se detecta antes de programar, puede corregirse con una conversación. Si se detecta luego de construir muchas pantallas, servicios y pruebas, el costo aumenta.
Cuando un defecto llega a producción, el costo puede ser aún mayor:
Por eso una de las metas del testing es detectar problemas lo antes posible, especialmente los que tienen mayor impacto.
A veces se piensa que el testing solo sirve después de programar. Sin embargo, también puede prevenir defectos antes de que existan en el código.
Por ejemplo, cuando una persona con mirada de testing revisa un requisito, puede detectar preguntas importantes:
Estas preguntas pueden evitar ambigüedades. Cuanto más claro sea el comportamiento esperado, menos espacio habrá para interpretaciones incorrectas.
Un sistema puede estar técnicamente bien construido y aun así no resolver correctamente la necesidad del usuario. Por eso el testing también debe mirar el producto desde la experiencia real de uso.
Algunas preguntas útiles son:
Probar desde la perspectiva del usuario no reemplaza las pruebas técnicas, pero agrega una mirada fundamental: comprobar si el software es útil en la práctica.
Una regresión ocurre cuando algo que antes funcionaba deja de funcionar después de un cambio. Esto puede pasar al corregir un defecto, agregar una funcionalidad, actualizar una biblioteca o modificar una configuración.
Por ejemplo, un equipo cambia la forma de calcular descuentos para una promoción nueva. La promoción funciona, pero se rompe el cálculo de descuentos antiguos. Si no se prueban los casos anteriores, el defecto puede llegar a producción.
Por eso las pruebas no solo se ejecutan sobre funcionalidades nuevas. También se repiten sobre funcionalidades existentes para confirmar que el sistema sigue comportándose correctamente.
Los casos de prueba, cuando están bien escritos, funcionan como una forma de documentación. Describen cómo se espera que el sistema se comporte ante distintas condiciones.
Esta documentación ayuda a varias personas:
Una prueba clara no solo sirve en el momento de ejecutarla. También conserva conocimiento útil para futuras versiones.
La falta de pruebas puede generar consecuencias visibles y costosas. Algunas de las más comunes son:
No probar puede parecer más rápido al principio, pero suele aumentar el costo y la incertidumbre a medida que el sistema crece.
Probar bien no significa ejecutar una cantidad enorme de casos sin pensar. Significa elegir pruebas útiles, observar con atención y comunicar los resultados de forma clara.
Una buena actividad de testing tiene varias características:
La calidad del testing depende más del análisis que de la cantidad de pasos ejecutados.
Imaginemos que un equipo debe decidir si publica una nueva versión de una tienda en línea. El testing puede aportar información como esta:
| Aspecto evaluado | Información obtenida | Impacto en la decisión |
|---|---|---|
| Calidad | El registro, la búsqueda de productos y el pago funcionan correctamente. | Aumenta la confianza en los flujos principales. |
| Riesgo | Se detectó un error menor en el texto de una pantalla administrativa. | Puede publicarse si el equipo acepta ese riesgo. |
| Confianza | Las pruebas críticas fueron ejecutadas y documentadas. | La decisión se toma con evidencia, no solo con intuición. |
Este ejemplo muestra que el testing no entrega únicamente una respuesta de "sí" o "no". Entrega información para evaluar el estado real del producto.
Probamos software porque desarrollar aplicaciones implica incertidumbre. Puede haber requisitos ambiguos, errores humanos, combinaciones no previstas, cambios que rompen funcionalidades existentes y riesgos que no siempre son visibles al principio.
El testing reduce esa incertidumbre. No elimina todos los defectos ni garantiza perfección, pero permite conocer mejor el producto, descubrir problemas relevantes y tomar decisiones con más información.
En el próximo tema estudiaremos con mayor precisión la diferencia entre error, defecto, falla e incidencia, términos fundamentales para comunicar problemas de manera profesional.