Principio 1: Las pruebas muestran la presencia, no la ausencia de defectos

Definición y Alcance

Este principio establece que el objetivo principal de las pruebas es encontrar defectos en el software. Sin embargo, no importa cuántas pruebas se realicen o cuán rigurosas sean, nunca se puede garantizar que el sistema esté completamente libre de errores. Nuestras pruebas solo pueden demostrar los defectos que estén presentes, pero no podemos asegurar la ausencia de todos los defectos.

El propósito de las pruebas es reducir la posibilidad de que existan errores significativos en el software. Aun si no se encuentran errores después de realizar muchas pruebas, siempre existe la posibilidad de que algunos defectos estén ocultos. Este principio refuerza la idea de que las pruebas no son una herramienta para garantizar la perfección del software, sino más bien una forma de minimizar los riesgos asociados a su entrega.

Explicación

La actividad de probar el software es sumamente importante para detectar defectos y evaluar la calidad del producto que estamos desarrollando. A medida que vamos ejecutando los casos de prueba, nuestro objetivo es identificar cualquier comportamiento anómalo o que no cumpla con los requisitos especificados en la historia de usuario y sus criterios de aceptación. Sin embargo, el hecho de que un conjunto de pruebas no detecte errores no significa que el software esté libre de fallos. La naturaleza compleja del software (que se esté desarrollando o desarrollado) y los entornos en los que opera (entorno de prueba, entorno pre productivo, entorno productivo)  implica que siempre puede haber escenarios no cubiertos por las pruebas que resultan en defectos no detectados.

En proyectos ágiles, donde los ciclos de desarrollo son rápidos y las entregas frecuentes (recuerda que pueden ser ciclos de 2 semana a 1 mes), este principio es especialmente importante. Los equipos ágiles deben ser conscientes de que, aunque se ejecuten pruebas en cada sprint, no se puede garantizar que el software esté completamente libre de errores al final de cada iteración. La clave es identificar los defectos más críticos y gestionar los riesgos de manera efectiva, pero siempre con la comprensión de que los defectos podrían estar presentes.

Ejemplo

Tomando como ejemplo el proyecto de la aplicación web para vender paquetes turísticos. En una iteración, el desarrollador con el cual trabajamos implementa la funcionalidad “Buscar paquete” en ambiente de PRUEBA o QA. Como testers ágiles, ejecutamos varias pruebas para verificar que al ingresar destinos y fechas específicas, los resultados de búsqueda se muestren correctamente. Si no encontramos ningún defecto durante estas pruebas, ¿significa esto que la funcionalidad está perfecta? No necesariamente. Podrían existir errores en condiciones que no hayamos probado, como en la integración con otros módulos del sistema o en dispositivos móviles específicos. Aunque no se encuentren defectos en las pruebas, no se puede asumir que la funcionalidad está libre de defectos en todas las situaciones.

Momento para reflexionar:

Las pruebas nos ayudarán a identificar defectos, pero nunca podremos garantizar que el sistema esté completamente libre de ellos. Por ese motivo es tan importante analizar los criterios de aceptación y alcance de la historia de usuario, conversar con el equipo, fundamentalmente con nuestro Product Owner para ponernos de acuerdo con el alcance de nuestros casos de prueba.

Ten en cuenta que el programa de estudios de ISTQB CTFL v4.0 lo puedes bajar desde la página de recursos de Brightest, donde podrás ver los otros programas de estudios de ISTQB® - International Software Testing Qualifications Board y los de Performance Testing United Selenium United Agile United Artificial Intelligence United

De más está decir que sigo publicando contenidos en mi blog.

Muchas gracias por seguirme.