Siete principios del proceso de prueba

Continuando con la linea del post de la importancia de las pruebas de software quiero compartirles los 7 principios del proceso de prueba básico.

• Principio 1: El proceso de prueba demuestra la presencia de defectos
  • El proceso de prueba puede probar la presencia de defectos
  • Las desviaciones identificadas a lo largo del proceso de prueba demuestran la presencia de un fallo
  • La causa de un fallo puede no ser obvia
  • El proceso de prueba no puede demostrar la ausencia de defectos
  • Las pruebas reducen la probabilidad de la presencia de defectos que permanezcan sin ser detectados. La ausencia de fallos no demuestran la corrección de un producto software
  • El mismo proceso de prueba puede contener errores
  • Las condiciones de prueba pueden ser inapropiadas para detectar errores

Con mis palabras, lo que podemos sacar de este principio es que, por mas que probemos un aplicacion nunca podemos decir que el sistema se encuentra al 100% en su calidad de software, y esto lo decimos es porque no podemos estar seguros de que la aplicación ya no tiene defectos.

• Principio 2: No es posible realizar pruebas exhaustivas
  • Pruebas exhaustivas (“exhaustive testing”)
    • Enfoque de prueba donde el conjunto de pruebas abarca todas las combinaciones de valores de entrada y precondiciones
  • Explosión de casos de prueba (“test case explosion”)
    • Define el incremento factorial de esfuerzo y coste en el caso de pruebas exhaustivas
  • Prueba de Muestra (“sample test”)
    • La prueba incluye solamente un subconjunto (generado de forma sistemática o aleatoria) de todos los posibles valores de entrada

En condiciones reales, se utilizan generalmente una prueba de una muestra. Probar todas las combinaciones posibles de entradas y precondiciones sólo es económicamente viable en casos triviales

• Principio 3: Pruebas tempranas (“early testing”)
  • Cuanto más temprana es la detección de un defecto, menos costosa es su corrección
  • Se obtiene una máxima rentabilidad cuando los errores son corregidos antes de la implementación
  • Los conceptos y especificaciones también pueden ser probados
  • Los defectos detectados en la fase de concepción son corregidos con los menores esfuerzo y coste
  • La preparación de una prueba también consume tiempo
  • El proceso de prueba implica más que sólo la ejecución de la prueba
  • Las actividades de prueba pueden ser preparadas antes de que el desarrollo se haya completado
  • Las actividades de prueba (incluidas las revisiones) deben se ejecutadas en paralelo a la especificación y diseño software

Las pruebas no solo son sobre el software funcionando, podemos empezar desde mucho antes, desde la misma documentación, los probadores tenemos una gran capacidad de análisis, buscando todos los caminos y variantes que se pueden presentar, es por esto que apoyamos mucho con nuestra revisión temprana a la documentación, también durante el proceso de desarrollo de software.

• Principio 4: Agrupamiento de defectos (“defect clustering”)
  • !Encuentre un defecto y encontrará más defectos “cerca”!
    • -Los defectos aparecen agrupados como hongos o cucarachas
    • -Vale la pena investigar un mismo módulo donde se ha detectado un defecto
  • Los probadores (“testers”) deben ser flexibles
    • Habiendo sido detectado un defecto, es conveniente volver a considerar el rumbo de las pruebas posteriores
    • La identificación/localización de un defecto puede ser investigada con un mayor grado de detalle, por ejemplo, realizando pruebas adicionales o modificando pruebas existentes

Si encuentras un bug en un componente, es muy probable que hayan más. Con lo que una posible estrategia sería centrarse en mejorar las pruebas de aquellos componentes para los que se han reportado un número mayor de bugs, para ser más eficaces a la hora de cazarlos en fases tempranas.

• Principio 5: Paradoja del pesticida
  • Repetir pruebas en las mismas condiciones no es efectivo
    • Cada caso de prueba debe contar con una combinación única de parámetros de entrada para un objeto de prueba particular, de lo contrario no se podrá obtener información adicional
    • Si se ejecutan las mismas pruebas de forma reiterada no se podrán encontrar nuevos defectos (“defects”)
  • Las pruebas deben ser revisadas/modificadas regularmente para los distintos módulos de código
    • Es necesario repetir una prueba tras una modificación del código (corrección de defectos, nueva funcionalidad)
    • La automatización de pruebas puede resultar conveniente si un conjunto de casos de prueba se debe ejecutar con frecuencia

Según este principio un plan de pruebas va perdiendo efectividad conforme se ejecuta sucesivas veces. Con lo que cada vez tenderá a encontrar menos bugs… ¡lo que no significa que no hayan! (vuelve a leer el primer principio).

• Principio 6: Las pruebas dependen del contexto
  • Las pruebas se llevan a cabo de forma diferente en diferentes contextos
  • Objetos de prueba diferentes son probados de forma diferente
  • El controlador del motor de un coche requiere pruebas diferentes respecto de aquellas para una aplicación de “e-Commerce”
  • Entorno de prueba (“test environment”, cama de prueba – “test bed”) vs. entorno de producción (“production environment”)
  • Las pruebas tienen lugar en un entorno distinto del entorno de producción.
  • El entorno de prueba debe ser muy similar al entorno de producción
  • Siempre habrá desviaciones entre el entorno de prueba y el entorno de producción. Estas desviaciones ponen en tela de juicio las conclusiones que se obtuvieran tras las pruebas

• Principio 7: La falacia de la ausencia de errores
  • Un proceso de prueba adecuado detectará los fallos más importantes
  • En la mayoría de los casos el proceso de prueba no detectará todos los defectos del sistema (ver Principio 2), pero los defectos más importantes deberían ser detectados
  • Esto por sí solo no prueba la calidad del software
    • La funcionalidad del software puede no satisfacer las necesidades y expectativas de los usuarios
    • No se puede introducir la calidad a través de las pruebas, la calidad tiene que construirse desde el principio!

Estos son los 7 principios del proceso de prueba, espero les ayude !!