Vinculación de los siete principios de la prueba

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

Los siete principios de la prueba están interrelacionados y se complementan entre sí. A continuación, te comparto cómo estos principios están vinculados y por qué motivo nos puede ayudar para guiar nuestra estrategia de prueba:

1. Las pruebas muestran la presencia, no la ausencia de defectos

Este principio establece que el objetivo de las pruebas es encontrar defectos, pero nunca se puede garantizar que el software esté libre de ellos. Aquí es donde se vincula con otros principios como:

  • Pruebas exhaustivas son imposibles (Principio 2): Dado que no es posible probar todas las combinaciones posibles de entradas y escenarios, siempre existe la posibilidad de que algunos defectos no se detecten, lo que refuerza la idea de que las pruebas nunca podrán garantizar la ausencia total de errores.
  • Falacia de la ausencia de defectos (Principio 7): Incluso si las pruebas no encuentran defectos, esto no significa que el software esté libre de errores o que cumpla con las expectativas del usuario. Ambos principios refuerzan la noción de que el software siempre puede contener errores ocultos.

2. Las pruebas exhaustivas son imposibles

La imposibilidad de probar todas las combinaciones de entradas, salidas y condiciones se relaciona con varios otros principios:

  • Pruebas tempranas ahorran tiempo y dinero (Principio 3): Dado que no se pueden realizar pruebas exhaustivas, es clave identificar y corregir los defectos lo antes posible en el ciclo de vida del software. Esto permite que nos concentremos en las áreas más críticas del sistema.
  • Los defectos se agrupan (Principio 4): La imposibilidad de pruebas exhaustivas también lleva a la priorización de las pruebas en áreas más propensas a defectos, lo cual está alineado con el principio de que los defectos tienden a concentrarse en ciertos módulos o componentes.

3. Las pruebas tempranas ahorran tiempo y dinero

Este principio se vincula directamente con la idea de optimización de esfuerzos y recursos:

  • Pruebas exhaustivas son imposibles (Principio 2): Como no es posible probar todo, es fundamental comenzar las pruebas lo antes posible para detectar errores en las etapas iniciales y reducir los costos de corrección.
  • Pruebas se desgastan (Principio 5): Las pruebas tempranas no solo permiten encontrar errores a tiempo, sino que también permiten modificar y actualizar los casos de prueba a medida que el software evoluciona, evitando el desgaste de las pruebas estáticas.

4. Los defectos se agrupan

Este principio resalta que una gran parte de los defectos tiende a concentrarse en un pequeño número de módulos o componentes, lo que está vinculado con:

  • Pruebas exhaustivas son imposibles (Principio 2): Debido a que no es posible probar todo, debemos concentrar nuestros esfuerzos en esas áreas propensas a fallos, lo que refuerza la idea de priorizar pruebas en los puntos críticos del sistema.
  • Pruebas dependen del contexto (Principio 6): Dependiendo de la criticidad y el contexto del sistema, debemos ajustar nuestras estrategias de prueba y priorizar los módulos donde se espera mayor concentración de defectos.

5. Las pruebas se desgastan

El desgaste de las pruebas implica que las pruebas repetitivas pierden efectividad, lo que tiene una relación directa con:

  • Pruebas exhaustivas son imposibles (Principio 2): Como no se puede probar todo y las pruebas pueden perder eficacia con el tiempo, debemos actualizar continuamente nuestros casos de prueba para mantener su relevancia.
  • Falacia de la ausencia de defectos (Principio 7): Las pruebas que no encuentran defectos pueden llevar a la falsa conclusión de que el sistema está libre de errores, pero, al desgastarse, las pruebas pueden dejar de detectar errores ocultos.

6. Las pruebas dependen del contexto

Este principio establece que las pruebas deben adaptarse al entorno y tipo de software que se esté desarrollando:

  • Los defectos se agrupan (Principio 4): En ciertos contextos, como sistemas críticos, es probable que los defectos se agrupen en áreas específicas, lo que requiere enfoques de prueba más rigurosos y exhaustivos.
  • Pruebas exhaustivas son imposibles (Principio 2): Dado que no es posible probar todo, debemos ajustar nuestras estrategias de prueba dependiendo del contexto del proyecto, enfocándonos en áreas críticas según el riesgo y el tipo de software.

7. Falacia de la ausencia de defectos

Este principio enfatiza que la ausencia de defectos visibles no garantiza la perfección del software, vinculándose con:

  • Las pruebas muestran la presencia, no la ausencia de defectos (Principio 1): Ambos principios refuerzan la idea de que las pruebas nunca pueden garantizar que el software esté libre de errores.
  • Pruebas se desgastan (Principio 5): Incluso si las pruebas no encuentran defectos, es posible que estos existan y no hayan sido detectados debido al desgaste de las pruebas o a escenarios no cubiertos.

Los siete principios de la prueba están interconectados porque abordan diferentes aspectos del proceso de testing y se complementan entre sí para proporcionar un enfoque equilibrado y realista del testing de software. En conjunto, los principios reconocen que:

  • No se puede probar todo (Principio 2), pero las pruebas pueden detectar errores si se enfocan en las áreas correctas (Principios 1, 4 y 6).
  • Es fundamental empezar las pruebas temprano para reducir los costos (Principio 3) y mantener la salud de las pruebas a lo largo del ciclo de vida del software (Principio 5).
  • Los testers siempre deben estar conscientes de que la ausencia de defectos no significa que el software sea perfecto (Principio 7), y deben adaptar sus enfoques según el contexto del sistema (Principio 6).

Momento para reflexionar:

Estos 7 principios permiten que adoptemos un enfoque estratégico en nuestros procesos de control de calidad, priorizando las áreas que más impactan en la calidad total del software, y reconociendo las limitaciones que puedan existir en el proceso de pruebas. Después de un tiempo en esta práctica, uno termina dándose cuenta la importancia de estos conceptos y su aplicación en nuestras pruebas.

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.