Testing (III) - Análisis y resultados de las pruebas

Este es el tercero de una serie de artículos sobre el testing y el cmmi:

• Testing (I) - Las pruebas según el CMMi
• Testing (II) - Planificación de las pruebas
• Testing (III) - Analizar los resultados de las pruebas

Vamos a retomar esta serie de posts dedicados al testing.

Nos habíamos quedado en el post anterior en la planificación de las pruebas. Por supuesto, faltaría la realización de las pruebas según lo planificado. Pero para ello, me gustaría dedicar un exhaustivo análisis de la herramienta HP Quality Center que he tenido el placer de probar.

Vayamos pues a la etapa de análisis y resultados.

Recopilación de resultados

En primer lugar, hay que recopilar los resultados. Es decir, para poder hacer cualquier tipo de análisis, no basta con probar. Ni siquiera basta con apuntar los resultados. Hace falta que esos resultados estén consolidados en un repositorio.

¿Acaso no desarrollas tu código y después recopilas y unificas todo en un repositorio? Pues con las pruebas igual. Hay varias formas de hacerlo:

• Con herramientas como HP Quality Center que centralizan todo el proceso y se responsabilizan de las distintas fases y su integración.
• De forma manual con simples ficheros Excel, por ejemplo.

Análisis de los resultados de las pruebas 

• Con los resultados de las pruebas y el informe de pruebas presentes, se analizan los resultados para comprobar si se han cumplido los criterios que se especificaron para asegurar que la prueba ha sido exitosa. Los resultados de las pruebas de cada producto de trabajo tienen que figurar en los informes y éstos se tienen que analizar incrementalmente para poder darlos como correctos.
• Cuando el resultado de las pruebas no es el esperado y no está claro que el defecto resida en el producto, es útil estudiar el “cómo se hizo”, para descartar que los errores se deban a problemas de métodos, de criterios o del entorno de pruebas. De nuevo, las herramientas nos ayudarán a buscar el "porqué" de los resultados.

Hay que aclarar que en ocasiones esta fase de análisis no tiene porqué llevarla a cabo la misma persona que se encarga de las pruebas, ni tampoco los programadores. Aquí un buen rol de QA, o incluso el jefe de proyecto, puede aprovechar su experiencia para arrojar luz sobre los resultados. En entornos ágiles, el scrum master podría encargarse de esta tarea.

Comunicación de resultados de pruebas

Una vez se han analizado los resultados de las pruebas, llega la parte más desagradable para el personal técnico: la comunicación de resultados. La comunicación se hace a varios destinatarios:

• Al equipo de desarrollo. Es importante que sepan el estado del producto en cuanto a defectos encontrados, y una comparación respecto a fases anteriores o si es posible, respecto a otros proyectos más o menos similares. No se trata nunca de decir "lo hacemos mejor" o "lo hacemos peor". Este tipo de actitud es la mejor forma de cargarse las métricas.
• Al gerente y otros responsables del proyecto. Aquí es crucial dar un sentido de "vamos bien" o "hay que mejorar". Tratar de engañarse con un "no es tan malo como parece", es la mejor forma de llevar un proyecto al fracaso. Si los resultados son buenos, hay que ser realistas y no dejarse llevar por un falso entusiasmo, acortando plazos (por ejemplo).
• Al cliente. En numerosas situaciones, sobre todo en los entornos de testing y preproducción, el cliente estará al tanto del estado de defectos, y de los resultados de las pruebas. Es importante transmitir seguridad, y sobre todo, franqueza.

 

El próximo post debería ser por fin el que estoy preparando de automatización y gestión de pruebas con HP Quality Center como ejemplo.