Principio 7: Falacia de la ausencia de defectos

  • Autor de la entrada:
  • Categoría de la entrada:Agile / ISTQB

Definición y Alcance

Este principio advierte que, incluso si todas las pruebas han sido exitosas y se han corregido los defectos detectados, eso no garantiza que el sistema cumpla con las expectativas de los usuarios o que sea completamente libre de errores. Es un error suponer que un sistema sin defectos conocidos es necesariamente un sistema exitoso o adecuado. Un software puede pasar todas las pruebas y aún así fallar en cumplir con los objetivos comerciales o las expectativas del cliente.

Explicación

La verificación de un sistema (es decir, asegurarse de que el sistema haga lo que se especificó) no es suficiente para garantizar el éxito. También es necesario llevar a cabo la validación del sistema, es decir, asegurarse de que el software realmente satisface las necesidades y expectativas de los usuarios finales. En proyectos ágiles, donde los requisitos pueden evolucionar rápidamente, es crucial validar continuamente que el sistema no solo esté libre de errores técnicos, sino que también cumpla con los objetivos comerciales.

Ejemplo

Imaginemos que la funcionalidad «Buscar paquete» en una aplicación web de venta de paquetes turísticos ha pasado todas las pruebas funcionales sin ningún defecto aparente. A pesar de esto, los usuarios pueden encontrar que la funcionalidad es difícil de usar o que los resultados no son relevantes para sus necesidades. Aunque el sistema técnicamente funcione como se especificó, su éxito se mide por cómo satisface las expectativas y necesidades del cliente, no solo por la ausencia de defectos.

Momento para reflexionar:

Este principio también tiene implicaciones para la gestión de riesgos. Aunque el software pase todas las pruebas, todavía puede haber riesgos ocultos relacionados con el rendimiento, la seguridad o la satisfacción del usuario. Por lo tanto, es esencial no solo enfocarse en eliminar defectos técnicos, sino también en garantizar que el software tenga el valor deseado para los usuarios. Aquí hay varios aspectos a destacar, mencionar y pensar para realizar profesionalmente nuestra actividad, debemos siempre estar velando por el correcto alcance y actualización de la historia de usuario y sus criterios de aceptación, además de evaluar la viabilidad dependiendo de cada historia de usuario, de aplicar pruebas basadas en seguridad, pruebas basadas en riesgos y pruebas basadas en usabilidad, entre otras ya que también cabe pensar que para ciertas circunstancias, sean necesarias pruebas de performance.

Comentario final

Si te ha servido este contenido basado en el programa de estudios del ISTQB CTFL v4.0, me alegro y mucho. También te cuento que me puedes seguir en LinkedIn e interactuar con otros colegas testers que me siguen y que están interesados en contenidos relacionados con agile testinginteligencia artificial y OKRs aplicado a testing. Muchas gracias

Gus Terrera

Apasionado por el agile testing y la ia.