Durante el diseño y la ejecución de las pruebas debemos recoger diferentes métricas. La utilidad más habitual es informar al responsable del proyecto del estado del sistema bajo prueba: defectos encontrados, severidad de los mismos, etc.
Habitualmente también se recogen métricas para conocer el grado de cobertura que se ha conseguido con la ejecución de las pruebas: casos de prueba propuestos, ejecutados, fallidos, no ejecutados, bloqueados, etc.
Pero el responsable de pruebas debe prever también la recogida de información suficiente para hacer más efectivas las pruebas realizadas en cada iteración. "Hacer más efectiva" significa aquí detectar el mayor numero posible de errores, o errores más importantes.
Para esto, debemos pensar con antelación cual será nuestra estrategia de mejora de la efectividad, de cara a recoger la información necesaria. Algunas de las suposiciones que podemos seguir son:
Los errores tienden a "agruparse" (1):
En este caso, deberemos recoger información que nos permita trazar cada error detectado durante las pruebas con la zona en la que se ha producido. Una vez finalizado el ciclo de pruebas, podremos ver las zonas en las que debemos poner mayor atención en los siguientes ciclos de pruebas y en cuales podemos disminuir la intensidad o tomar medidas de mejora.
A la hora de determinar o analizar las zonas, podemos tener en cuenta los distintos factores que determinan el éxito o fracaso durante un proceso de test (2):
Referencias
lunes, 29 de enero de 2007
Optimizando la realización de pruebas: uso de métricas
jueves, 11 de enero de 2007
Sistemas que usan periféricos especiales
Muchos sistemas utilizan o se comunican con periféricos o dispositivos no estándares, como puede ser una puerta automática, una barrera, una impresora de billetes de metro o tren, etc. Ya que esta estrategia implica que el equipo de desarrollo tenga en cuenta en su trabajo las necesidades de pruebas (algo no muy habitual), es necesario conseguir que estas decisiones se tomen lo antes posible en el proyecto, y en el nivel de decisión adecuado que garantice que no se dejaran en el olvido cuando las presiones de tiempo lleguen. Esta tactica puede extrapolarse a cualquier comunicación que nuestro sistema tenga que realizar con otro sistema del que no dispondremos en nuestro entorno de pruebas, aplicando como siempre el criterio de coste/riesgo correspondiente.
En general, es difícil disponer de estos elementos en el entorno de pruebas, especialmente el interno (pruebas alfa, en las instalaciones del desarrollador, de verificación, como queramos llamarlas) ya sea por su tamaño, coste, disponibilidad en el tiempo o pertenecer a otra compañía.
Si no hemos tenido en cuenta esta circunstancia al realizar nuestra estrategia de pruebas (y por tanto, en el planteamiento general del proyecto) nos encontraremos con que el número de pruebas que podemos hacer antes de entregar nuestro producto está limitado por esta causa, y además en elementos cuyo fallo puede suponer un impacto importante en la calidad percibida por el cliente.
Una táctica para solventar este inconveniente es que cualquier implementación de comunicaciones con dichos dispositivos tenga un modo "de prueba" o "test", de tal forma que cuando el sistema está en este modo, la comunicación con el dispositivo es sustiuida por un metodo posible en el entorno de pruebas definido, como puede ser un fichero o impresora.
Este modo "test" debe cumplir con algunas características que nos permitan asegurar que su uso no desvirtua la prueba:
miércoles, 10 de enero de 2007
Oráculos
Para tener una prueba bien diseñada es necesario conocer de antemano el resultado de su ejecución. Un oráculo es un elemento o artefacto que nos permite conocer el resultado esperado de la ejecución de una prueba. Por ejemplo: Asi vemos que esta elección nos lleva a crear y mantener un oráculo de coste considerable en relación a la implementación en el sistema y cuya fiabilidad no es mucho mayor. En estos casos, siempre que sea posible, es más aconsejable utilizar como oráculo elementos reales que se hayan procesado en el pasado utilizando ese mismo cálculo. Ya que generalmente un sistema se construirá para sustituir a un proceso manual o a otro sistema obsoleto, el propio cliente será capaz de proporcionar datos (entradas, salidas) validados en la realidad.
- Otra aplicación o sistema.
- Un resultado calculado por un método manual
- Datos históricos cuya validez ya ha sido comprobada en la realidad
La utilización o no de determinados oráculos en nuestras pruebas es una decisión que debe plantearse, y resolverse en la medida de lo posible, en la fase de Estrategia, ya que pueden conllevar actividades de preparación que es necesario acometer antes del diseño y/o la ejecución de las pruebas.
En este sentido es necesario evaluar siempre el coste/beneficio de su utilización, la fiabilidad del oráculo y sus necesidades de mantenimiento.
Por ejemplo, es muy común que a la hora de verificar un sistema en el que está implicado un cálculo complejo, el equipo de pruebas se prepare como oráculo una hoja de cálculo (excel o similaar) que lo refleja. Esto conlleva, entre otros, los siguientes inconvenientes:
El proceso de pruebas
La gran mayoría de las metodologías de pruebas distinguen 5 actividades principales en el proceso de pruebas, aunque con nombres diferentes. Estas son:
- Planificación o Estrategia: que se va a hacer, cuando, como y quien lo hará, que necesidades es necesario satisfacer para llevarlo a cabo.
- Diseño de pruebas: que pruebas se van a a hacer y en que consiste cada una (condiciones, pasos, datos, resultados esperados)
- Construcción de pruebas: especialmente en el caso de pruebas automáticas, es necesario materializar el diseño en determinados artefactos (programas, scripts de herramientas de ejecución automatica).
- Ejecución: realización de las pruebas propiamente dichas. Todo lo anterior es la preparación para esta fase.
- Evaluación: análisis de los resultados obtenidos de cara a proporcionar un diagnóstico del sistema bajo prueba y del propio proceso de prueba.
Adicionalmente, hay otros procesos necesarios, que las metodologías suelen desarrollar:
- Seguimiento: para asegurar que las actividades se realizan de acuerdo a lo previsto o, en caso contrario, se toman las medidas adecuadas.
- Gestión de la configuración: para gestionar y controlar productos de entrada y salida de las distintas actividades, y sus relaciones entre ellos y con el sistema bajo prueba.