Gestión de Pruebas
2 Conocer e interpretar las métricas de prueba para la presentación de informes de prueba y control de prueba (Por ejemplo, los defectos encontrados y se fijaron, pruebas
que pasaron y la que no).
(K2)
3 Resumir el propósito y el contenido del resumen de la prueba documento de informe de acuerdo con [IEEE 829]. (K2)
En esta sección, vamos a revisar las técnicas y las métricas que se utilizan comúnmente para el seguimiento de la preparación y ejecución de pruebas. Nos centraremos especialmente en el uso y la interpretación de dichas métricas de prueba para la presentación de informes, el control y análisis del esfuerzo de la prueba, incluyendo las basadas en defectos y los basados en los datos de prueba.
También vamos a ver opciones para informar sobre el estado de prueba utilizando dichas métricas y otra información.
A medida que lea, recuerde que debe velar por el glosario de términos densidad de defectos, insuficiencia tasa, control de prueba, cobertura de la prueba, monitorización de las pruebas y el informe de prueba.
5.3.1 Seguimiento de la evolución de las actividades de prueba
Después de haber desarrollado nuestros planes, se definen nuestras estrategias y enfoques de prueba y estimamos el trabajo a realizar, ahora tenemos que seguir nuestro trabajo de pruebas que realizamos hacia fuera. Supervisión de Prueba puede servir a varios propósitos durante el proyecto, incluyendo el seguimiento:
• Dar al equipo de pruebas la retroalimentación de las pruebas, de cómo va el trabajo de pruebas, las oportunidades que permite, para orientar y mejorar las pruebas y el proyecto. • Proporcionar al equipo de proyecto la visibilidad de los resultados de las pruebas.
• Medir el estado de los elementos de prueba, la cobertura de prueba y comparar los elementos de la prueba frente a los criterios de salida para determinar si el trabajo de la prueba se realiza correctamente.
• Recopilar datos para su uso en la estimación de los esfuerzos de las pruebas futuras. Especialmente para proyectos pequeños, el líder de prueba o una persona delegada pueden reunir pruebas para llevar un seguimiento del progreso y control de la prueba con información de forma manual utilizando documentos, hojas de cálculo y bases de datos simples. Cuando se trabaja con grandes equipos, proyectos y distribuido los esfuerzos de prueba a largo plazo, nos encontramos con que la eficacia y la coherencia de los datos colectivos es ayudada por el uso de herramientas automatizadas (véase el Capítulo 6).
Una manera de reunir información del progreso de la prueba es utilizar el registro de la prueba IEEE 829 modelo. Si bien gran parte de la información relacionada con los eventos de registro puede ser capturados en un documento, preferimos para capturar la información de la prueba por prueba en hojas de cálculo (véase la Figura 5.1).
LOG plantilla de prueba IEEE 829 STANDARD
Identificador de registro de la prueba Entradas de actividad y de eventos (]Ejecución, descripción, resultados del procedimiento, información del ambiente, eventos anómalos, Identificadores de informe de incidente)
Descripción (piezas que se prueben, ambiente en el que la prueba es
llevado a cabo)
En la Figura 5.1, las columnas A y B muestran el ID de prueba y el caso de prueba o conjunto de pruebas nombre. El estado del caso de prueba se muestra en la columna C ( 'Warn' indica una prueba que dio lugar a una falla menor). Columna D muestra la configuración de prueba, donde los códigos de A, B y C corresponden a probar entornos descrito en detalle en el plan de pruebas. Las columnas E y F muestran el número de identificación de defectos (o error) (de la base de datos de seguimiento de defecto) y el número de prioridad de riesgo del defecto (Desde el 1, el peor de los casos, al 25, al menos riesgoso). Columna G muestra las iniciales del tester que corrió la prueba. Columnas H y L los datos de captura para cada prueba relacionada con fechas, el esfuerzo y la duración (en horas). Tenemos planeado para las métricas y el esfuerzo real y fechas completado la cual nos permitiría resumir el progreso en relación con el calendario y el presupuesto previsto. Esta hoja de cálculo también puede ser un resumen en términos del porcentaje de pruebas que han sido corridas y el porcentaje de pruebas que han pasado y han fallado.
Figura 5.1 podría mostrar una instantánea del progreso de la prueba durante la ejecución de la prueba por periodo, o tal vez incluso al cierre de la prueba si se considera aceptable para saltar algunas de las pruebas. Durante el análisis, diseño e implementación de las pruebas, una hoja de cálculo así mostraría el estado de las pruebas en función de su estado de desarrollo.
Además del estado de casos de prueba, también es común para monitorear el progreso de prueba durante el período de ejecución de la prueba observando el número de defectos encontrados y fijo. Figura 5.2 muestra un gráfico que traza el número total de defectos abierto y cerrado en el transcurso de la ejecución de la prueba hasta el momento.
También muestra el período de prueba de la fecha de finalización prevista y el número previsto de defectos que se encontrarán. Idealmente, como el proyecto se acerca al final planeado fecha, el número total de defectos abiertos se instalará en el número previsto y el número total de defectos corregidos convergerá con el número total abrió. Estos dos resultados nos dicen que hemos encontrado bastantes defectos para sentir cómoda que hemos terminado la prueba, que no tenemos ninguna razón para pensar que muchos más defectos están al acecho en el producto, y que todos los defectos conocidos han sido resuelto.
Gráficas tales como la Figura 5.2 también se pueden utilizar para mostrar las tasas de fracaso o defecto densidad. Cuando la fiabilidad es una preocupación fundamental, podríamos estar más preocupados por la frecuencia con la que se observan fallas que con el número de defectos que están provocando los fracasos. En las organizaciones que están buscando producir ultra-fiabilidad de software, se puede trazar el número de defectos sin resolver normalizados por el tamaño del producto, ya sea en miles de líneas de código fuente (KSLOC), en función puntos (FP) o alguna otra métrica de tamaño del código. Una vez que el número de defectos resueltos cae por debajo de un umbral predefinido, por ejemplo, tres por millones de líneas de código a continuación, el producto puede considerarse que cumplen con los criterios de salida densidad de defecto.
Medir el progreso de prueba basado en los defectos encontrados y fijo es común y útil si se usa con cuidado.
La métrica del avance de las pruebas a partir de los defectos detectados es frecuente y útil. Se debe evitar la utilización únicamente de esa métrica ya que es posible una
manipulación deliberadamente incorrecta por parte de otros actores intervinientes en el ciclo de vida de los defectos.
Dicho esto, el progreso de técnicas de pruebas de monitoreo varían considerablemente de las preferencias de los testers y las partes interesadas, las necesidades y objetivos del proyecto, los requisitos reglamentarios, las limitaciones de tiempo y de dinero y otros factores.
Además de los tipos de información que se muestran en el registro de la prueba IEEE 829 Plantilla, figuras 5.1 y Figura 5.2, otros sistemas de medición comunes para el progreso de prueba monitoreo incluye:
• El grado de terminación de la preparación entorno de prueba;
• La extensión de la cobertura de la prueba consiguió, comparada con los requisitos, riesgos, código, configuraciones u otras áreas de interés;
• El estado de la prueba (incluyendo el análisis, diseño e implementación) en comparación con diversos hitos de prueba;
• La economía de la prueba, tales como los costes y beneficios de la prueba continua ejecución en términos de encontrar el siguiente defecto o ejecutar la siguiente prueba. Como técnica de monitorización complementaria, es posible evaluar el nivel subjetivo de confianza que los testers tienen con los elementos de la prueba. Sin embargo, evite tomar
decisiones importantes basadas en evaluaciones subjetivas solo, con la impresión de la gente ya que tienen una forma de ser inexacta y coloreado por el sesgo.
5.3.2 Informes de estado de la prueba
monitoreo de progreso de la prueba se trata de la recopilación de los datos de prueba detallado; prueba de estado de la presentación de informes, se trata de comunicar con eficacia nuestros hallazgos a otros titulares del proyecto interesados. Al igual que con el control del progreso de prueba, en la práctica existe una gran variabilidad en como las personas informan el estado de pruebas, con las variaciones impulsadas por las preferencias de los testers y las partes interesadas, las necesidades y objetivos del proyecto, requisitos reglamentarios, limitaciones de tiempo y dinero y las limitaciones de las herramientas disponible para la presentación de informes. A menudo, las variaciones o resúmenes de las métricas utilizada para el control del progreso de prueba, tal como muestra la Figura 5.1 y Figura 5.2, se utilizan para informes de estado de prueba, también. Independientemente de las métricas específicas, gráficas e informes utilizado, informes de estado de prueba ayudan a los participantes del proyecto a comprender los resultados de un período de prueba, especialmente en lo que se refiere a los objetivos fundamentales del proyecto y si (o cuando) los criterios de salida estaban satisfechos.
Además de notificar a los interesados del proyecto sobre los resultados de la prueba, la presentación de informes de estado de la prueba es a menudo sobre esclarecedor e influir en ellos. Se trata de analizar la información y las métricas disponibles para apoyar las conclusiones, condiciones, y las decisiones sobre cómo orientar el proyecto hacia adelante o tomar otro comportamiento. Por ejemplo, podríamos estimar el número de defectos que quedan por descubrir, presentar los costos y beneficios de retrasar la fecha de lanzamiento para permitir más pruebas, evaluar los riesgos de los productos y de los proyectos restantes y ofrecer un dictamen sobre la confianza de las partes interesadas en la calidad del sistema bajo prueba.
Usted debe pensar en los informes de estado de prueba durante la planificación de las pruebas y períodos de preparación, ya que a menudo se necesitan para recopilar métricas específicas durante y al final de un período de prueba para generar los informes de estado de prueba de una manera efectiva y eficiente. Los datos específicos que querrá reunir dependerá de sus informes específicos, pero las consideraciones comunes incluyen los siguientes:
• ¿Cómo va a evaluar la adecuación de los objetivos de la prueba para un nivel de prueba dado y si se lograron los objetivos?
• ¿Cómo va a evaluar la adecuación del enfoque de prueba adoptado y si se apoya el logro de los objetivos de prueba del proyecto?
• ¿Cómo va a evaluar la eficacia de la prueba con respecto a estos objetivos y enfoques? Por ejemplo, si usted está haciendo la prueba basada en el riesgo, un objetivo principal de la prueba es someter los riesgos importantes de los productos, en la medida adecuada de la prueba. Mesa 5.1 muestra un ejemplo de un gráfico que permitiría informar de la cobertura de la prueba y los defectos no resueltos contra las principales áreas de riesgo producto que identificó en el análisis de riesgos. Si usted está haciendo las pruebas basadas en
requisitos, usted podría medir la cobertura en términos de requisitos o áreas funcionales en lugar de riesgos.
En algunos proyectos, el equipo de pruebas debe crear un informe de resumen de la prueba. Tal informe, creada ya sea en un hito clave o al final de un nivel de prueba, describe los resultados de un determinado nivel o fase de la prueba. La prueba estándar IEEE 829 Resumen plantilla de informe proporciona una guía útil para lo que sucede en tales un informe. Además de incluir el tipo de gráficos y tablas que se muestran anteriormente, es posible discutir los eventos importantes (especialmente problemáticas) que se produjeron Durante las pruebas, los objetivos de la prueba y si lo fueron, la prueba estrategia utilizada y lo bien que funcionó, y la eficacia global del esfuerzo de la prueba.
PRUEBA DE INFORME RESUMEN PLANTILLA: IEEE 829 STANDARD