El Testing de Software tiene principios que ayudan a entender sus posibilidades y sus límites. Estos principios son ideas generales que orientan la forma de planificar, diseñar y ejecutar pruebas.
Para un estudiante que recién comienza, conocer estos principios evita malentendidos comunes. Por ejemplo, muchas personas creen que si un sistema fue probado ya no tiene errores, o que probar más casos siempre significa probar mejor. En la práctica, el testing requiere criterio, selección de riesgos y comprensión del contexto.
En este tema estudiaremos los principios más importantes del testing y veremos ejemplos simples para comprenderlos.
Las pruebas pueden demostrar que existen defectos, pero no pueden demostrar que el software no tiene ninguno. Si ejecutamos diez pruebas y todas pasan, sabemos que el sistema se comportó correctamente en esas diez situaciones. No sabemos qué ocurrirá en todas las demás combinaciones posibles.
Por ejemplo, si probamos un formulario con datos válidos y funciona, eso no garantiza que también funcione con campos vacíos, datos muy largos, caracteres especiales, usuarios sin permiso o problemas de conexión.
Este principio enseña una idea clave: el testing aumenta la confianza, pero no entrega certeza absoluta.
En sistemas reales, probar todas las combinaciones posibles suele ser imposible. Incluso una pantalla simple puede generar una cantidad enorme de escenarios si combinamos campos, permisos, navegadores, estados del sistema, datos previos y errores externos.
Imaginemos un formulario con cinco campos. Si cada campo puede tomar diez valores relevantes, ya tenemos 100.000 combinaciones posibles. Si además agregamos distintos tipos de usuario, dispositivos y configuraciones, el número crece rápidamente.
Como no podemos probar todo, necesitamos seleccionar. Para eso usamos criterios como:
Probar bien no significa probar infinitamente, sino elegir pruebas con valor.
Cuanto antes se detecta un defecto, más fácil suele ser corregirlo. Si un requisito está mal escrito y se detecta antes de programar, puede corregirse con una aclaración. Si se detecta después de construir varias pantallas y servicios, el cambio puede requerir mucho más trabajo.
Las pruebas tempranas no significan ejecutar el sistema antes de que exista. También incluyen revisar requisitos, analizar criterios de aceptación, hacer preguntas y detectar inconsistencias en documentación o diseño.
Ejemplos de testing temprano:
El testing temprano ayuda a prevenir defectos, no solo a encontrarlos después.
En muchos proyectos, los defectos no se distribuyen de manera uniforme. Algunas zonas del sistema concentran más problemas que otras. Esto puede ocurrir por complejidad, cambios frecuentes, código antiguo, requisitos poco claros o integraciones delicadas.
Por ejemplo, una aplicación puede tener pocas fallas en pantallas de consulta, pero muchos problemas en el módulo de facturación porque allí existen reglas complejas, cálculos, permisos e integración con servicios externos.
Este principio nos ayuda a priorizar. Si una zona concentra defectos, conviene prestarle más atención:
Encontrar muchos defectos en una parte del sistema puede ser una señal de que hay riesgos más profundos.
Si ejecutamos siempre las mismas pruebas, llegará un momento en que esas pruebas dejarán de encontrar defectos nuevos. Esto se conoce como la paradoja del pesticida: usar siempre el mismo método reduce su capacidad para descubrir nuevos problemas.
Esto no significa que debamos descartar las pruebas existentes. Muchas siguen siendo útiles para regresión. Pero también debemos revisar, actualizar y ampliar los casos cuando el sistema cambia.
Algunas formas de evitar este problema son:
Un conjunto de pruebas debe evolucionar junto con el producto.
No se prueba de la misma manera una red social, un sistema bancario, una aplicación médica, un videojuego, una tienda en línea o una herramienta interna de administración. Cada producto tiene riesgos, usuarios y prioridades diferentes.
El contexto define qué pruebas son más importantes. Por ejemplo:
| Contexto | Riesgo importante | Pruebas prioritarias |
|---|---|---|
| Sistema bancario | Cálculos incorrectos, accesos no autorizados, pérdida de datos. | Funcionales, seguridad, integridad de datos, auditoría. |
| Tienda en línea | Errores en pagos, stock, precios o promociones. | Flujos de compra, integración con pagos, regresión. |
| Aplicación informativa | Contenido incorrecto, mala visualización, enlaces rotos. | Compatibilidad, usabilidad, revisión de contenido. |
| Sistema médico | Datos clínicos incorrectos o decisiones críticas mal soportadas. | Validación funcional estricta, seguridad, trazabilidad. |
No existe una estrategia universal que sirva igual para todos los proyectos. Un buen tester adapta su enfoque al contexto.
Un sistema puede tener pocas fallas visibles y aun así no servir al usuario. Si el producto no resuelve la necesidad real, si es difícil de usar o si implementa requisitos equivocados, puede fracasar aunque muchas pruebas pasen.
Por ejemplo, una aplicación de turnos médicos podría funcionar técnicamente bien: permite iniciar sesión, elegir especialidad y confirmar una reserva. Pero si no permite filtrar por obra social, ubicación o disponibilidad real, quizás no sea útil para los pacientes.
Por eso el testing también debe considerar validación, usabilidad, reglas de negocio y valor real, no solo la ausencia de errores técnicos.
Los principios anteriores muestran que el testing trabaja con información incompleta. Nunca podemos asegurar que revisamos absolutamente todo, pero sí podemos aumentar la confianza mediante pruebas bien elegidas.
La certeza implicaría saber que no existe ningún defecto. En software real, eso casi nunca es posible. La confianza, en cambio, se construye con evidencia: casos ejecutados, resultados correctos, defectos corregidos, riesgos conocidos y criterios de aceptación cumplidos.
Un equipo profesional no dice "el sistema no tiene errores". Dice algo más preciso:
Esta forma de comunicar es más realista y útil para tomar decisiones.
Supongamos que debemos probar una nueva funcionalidad para restablecer contraseña. Aplicar los principios anteriores nos llevaría a pensar así:
Los principios no son teoría aislada. Ayudan a tomar mejores decisiones al diseñar pruebas reales.
Cuando un equipo no comprende los principios del testing, puede caer en prácticas poco efectivas:
Estas prácticas pueden dar una falsa sensación de control, pero no necesariamente reducen los riesgos importantes.
| Principio | Idea principal |
|---|---|
| Las pruebas muestran defectos | Encontrar defectos es posible; demostrar que no existe ninguno, no. |
| No se puede probar todo | Debemos seleccionar pruebas según riesgo, impacto y valor. |
| Pruebas tempranas | Detectar problemas antes reduce costo y retrabajo. |
| Agrupamiento de defectos | Algunas áreas concentran más problemas que otras. |
| Paradoja del pesticida | Repetir siempre lo mismo pierde efectividad para encontrar nuevos defectos. |
| Dependencia del contexto | La estrategia de prueba debe adaptarse al producto y sus riesgos. |
| Ausencia de errores no implica utilidad | El producto también debe resolver la necesidad real del usuario. |
Los principios fundamentales del testing nos ayudan a tener una visión realista. Probar software no consiste en ejecutar casos sin límite ni en prometer perfección. Consiste en obtener información valiosa sobre calidad y riesgo mediante pruebas bien pensadas.
Comprender estos principios permite planificar mejor, priorizar con criterio, comunicar resultados de forma honesta y adaptar el esfuerzo de pruebas al contexto del proyecto.
En el próximo tema estudiaremos cómo encaja el testing dentro del ciclo de vida del software, desde la idea inicial hasta el mantenimiento de una aplicación en uso.