GESTIÓN DE INCIDENTES

1 Reconocer el contenido del informe [IEEE 829] incidente. (KL)

2 Escribir un informe de incidente que cubre la observación de una falla durante pruebas. (K3)

Vamos a ver este capítulo sobre gestión de pruebas con un tema importante:

¿Cómo podemos documentar y gestionar las incidencias que se produzcan durante la ejecución de pruebas? Vamos a ver lo que los temas que debemos cubrir cuando los incidentes de informes y defectos. Al final de esta sección, usted estará listo para escribir un informe a fondo de incidente.

Mantenga sus ojos abiertos para el único término del programa de estudios en esta sección, incidente de registro de datos (incident logging).

5.6.1 ¿Cuáles son los informes de incidentes y cómo puedo escribir bien ¿Cuáles? Cuando se ejecuta una prueba, es posible observar que los resultados reales son diferentes a los resultados esperados. Esto no es algo malo uno de los principales objetivos de las pruebas es encontrar problemas. Diferentes organizaciones tienen diferentes nombres para describir este tipo de situaciones.

Comúnmente, se llaman incidentes, errores, defectos, problemas o cuestiones.

Para ser precisos, a veces hacer una distinción entre incidentes, en una mano y defectos o errores en el otra. Un incidente es cualquier situación en la que el sistema exhibe un comportamiento cuestionable, pero a menudo nos referimos a un incidente como un

defecto únicamente cuando la causa es algún problema en el tema (Item) que estamos probando.

Otras causas de los incidentes incluyen una mala configuración o el fracaso del ambiente prueba, datos de prueba corruptos, malas pruebas, resultados esperados no válidos y errores probados. (Sin embargo, en algunos casos, la política es clasificar como

un defecto de cualquier incidencia que surge a partir de un diseño de la prueba, el entorno de prueba o cualquier otra cosa, que está bajo la administración de configuración formal.) Hablamos de incidentes que indiquen la posibilidad de que un comportamiento cuestionable no es necesariamente un defecto verdadero. Nosotros registrar estos incidentes para que tengamos un registro de lo que hemos observado y podemos seguir el incidente y realizar un seguimiento de lo que se hace para corregirlo.

Si bien es más común encontrar el registro de incidentes o notificación de defectos procesos y herramientas en uso durante las fases de prueba formales, independientes, también puede registro, informe, seguimiento y gestión de incidencias encontradas durante el desarrollo y revisiones. De hecho, esta es una buena idea, ya que le da información útil sobre la medida en que los principios y es más económica las actividades de detección y eliminación de defectos.

Por supuesto, también necesitamos alguna forma de presentación de informes, el seguimiento y la gestión de incidentes que se producen en el campo o después de la implementación del sistema. Mientras que muchos de estos incidentes se producen por fallas humanas o algún otro comportamiento no relacionada con un defecto, un porcentaje de defectos escapan del control de calidad y pruebas de actividades. El porcentaje de detección de defectos, lo que se compara campo de defectos con la prueba de los defectos, es una medida importante de la eficacia del proceso de prueba.

He aquí un ejemplo de una fórmula DDP que se aplicaría para el cálculo de DDP para el último nivel de la prueba antes de su liberación en el campo:

Es más común encontrar defectos notificados en contra del código o el sistema sí mismo. Sin embargo, también hemos visto casos en que se describen los defectos en contra de requisitos y especificaciones de diseño, guías del usuario y del operador y pruebas.

A menudo, ayuda a la eficacia y eficiencia de la presentación de informes, el seguimiento y la gestión de defectos cuando la herramienta de seguimiento de defecto proporciona una capacidad de variar algunas de las informaciones capturadas en función de lo que se informó en contra del defecto.

En algunos proyectos, se encuentran un gran número de defectos. Incluso en el más pequeño proyectos en los que se encuentran 100 o menos defectos, se puede perder fácilmente un seguimiento de ellos a menos que tenga un proceso para la presentación de informes, clasificación, asignación y gestión de defectos del descubrimiento a la resolución final.

Un informe de incidente contiene una descripción de la mala conducta que era observada y la clasificación de la mala conducta. Al igual que con cualquier

comunicación escrita, que ayuda a tener objetivos claros en mente al escribir. Un objetivo común para tales informes es proporcionar a los programadores, administradores y otros con detallada información sobre el comportamiento observado y el defecto. Otra es la de apoyar el análisis de las tendencias de agregar defectos a los datos, ya sea para comprender más sobre un conjunto particular de problemas o pruebas o para la comprensión y la presentación de informes en el nivel global de la calidad del sistema. Por último, informes de defectos, cuando se analizaron a través de un proyecto e incluso a través de proyectos, dar información que puede conducir al desarrollo y mejoras en los procesos de prueba.

Al escribir un incidente, que ayuda a tener los lectores en mente, también. Los programadores necesitan la información de la memoria para encontrar y corregir los defectos antes de que ocurre, sin embargo,previo a que esto suceda, los líderes deberán analizar y priorizar los defectos con el fin de asignar eficientemente los recursos disponibles. Debido a que algunos defectos pueden ser diferidos, tal vez para fijarse más tarde o quizás, en última instancia, a no ser fijo en todos debemos incluir soluciones temporales y otros datos útiles para el servicio de asistencia o soporte de equipos técnicos. Por último, los testers a menudo necesitan saber lo que sus colegas están encontrando, que puedan ver un comportamiento similar en otro lugar y evitar tratar de ejecutar las pruebas que serán bloqueados.

Un buen informe de incidente es un documento técnico. Además de ser claro para sus objetivos y la audiencia, cualquier buen informe surge de un enfoque cuidadoso para investigar y escribir el informe. Tenemos algunas reglas básicas que pueden ayudar a escribir un buen informe de incidente.

En primer lugar, utilizar un enfoque cuidadoso, atento a la ejecución de las pruebas. Nunca se sabe cuándo se va a encontrar un problema. Si usted está golpeando el teclado mientras charla con los compañeros de oficina o soñando con una película que acaba de ver, es posible que no se dé cuenta de comportamientos extraños. Incluso si usted ve el incidente, ¿cuánto es lo que realmente sabe sobre él? ¿Qué se puede escribir en un informe de incidente? síntomas intermitentes o esporádicos son un hecho de la vida para algunos defectos y es siempre desalentador tener un informe de incidente rebotando como 'irreproducible '. Por lo tanto, es una buena idea tratar de reproducir los síntomas cuando los vea esta puede ser una buena regla de oro. Si tiene un defecto con síntomas intermitente, todavía tendríamos que informar que seguirían, pero nos gustaría asegurarnos de incluir tanta información como sea posible, especialmente el número de veces que intentamos reproducir y las veces que de hecho ocurrió.

También debe tratar de aislar el defecto mediante cambios cuidadosamente elegidos a los pasos utilizados para reproducirlo. Al aislar el defecto, usted ayuda a guiar el programador a la parte problemática del sistema. También aumenta su propio conocimiento de cómo funciona el sistema y cómo se produce un error.

Algunos casos de prueba se centran en las condiciones de frontera, lo que puede hacer que parezca que un defecto no es probable que suceda con frecuencia en la práctica. Hemos encontrado que es una buena idea para buscar condiciones más generalizadas que causen esa falla de ocurrir, en lugar de simplemente confiar en el caso de

prueba. Esto ayuda a prevenir el duplicado de informe de incidente, 'Ningún usuario real va a hacer esto otra vez. " También reduce el número de informes duplicados que quedan archivados.

Como a menudo hay una gran cantidad de pruebas pasando con el sistema durante un período de prueba, hay un montón de otros resultados de las pruebas disponibles. Comparación de un problema observado contra otros resultados de la prueba y los defectos conocidos que se encuentran es una buena manera de encontrar y documentar la información adicional que el programador es muy probable que encuentre útil. Por ejemplo, es posible comprobar si hay síntomas similares observados con otros defectos, los mismos síntomas observados con defectos que se fijaron en las anteriores versiones o resultados similares (o diferentes) observada en las pruebas que cubren partes similares del sistema.

Muchos lectores de informes de incidentes, especialmente los gerentes, serán necesarios para comprender y soportar la prioridad y la gravedad del defecto. Por lo tanto, el impacto del problema en los usuarios, clientes y otras partes interesadas es importante. La mayoría de seguimiento de defectos de sistemas tienen un campo de título o resumen y ese campo deben mencionar el impacto, también.

Elección de las palabras, sin duda importa en los informes de incidentes. Usted debería ser claro y sin ambigüedades. También debe ser neutral, centrado e imparcial, teniendo en cuenta los problemas interpersonales relacionados con las pruebas discutido en Capítulo 1 y al principio de este capítulo. Por último, mantener el informe conciso ayuda a mantener la atención de la gente y evita el problema de la pérdida de ellos en detalles. Como última regla de oro para los informes de incidentes, se recomienda que utilice una proceso de revisión de todos los informes presentados. Funciona si usted tiene la opinión tester en la revisión de informes y hemos permitido también que los testers, al menos los experimentados revisen los informes de otros testers. Los comentarios son técnicas probadas de garantía de calidad e informes de incidentes son importantes entregables del proyecto. 5.6.2 Lo que va en un informe de incidente?

Un informe de incidente describe una situación, comportamiento o evento que ocurrió durante las pruebas que requiere más investigación. En muchos casos, un incidente consta de un informe de una o dos pantallas, llenas de información recogida por un defecto herramienta de seguimiento y se almacena en una base de datos.

Como se mencionó anteriormente, a menudo se documenta la información narrativa como un resumen, los pasos para reproducir, las etapas de aislamiento juzgados y el impacto del problema. Estos campos deben mencionar las entradas dadas y salidas observadas, la discrepancia o la varianza de las expectativas, las diferentes formas en que podría y no podía hacer que se repite el problema y el impacto. La información que un tester proporcionaría incluye la fecha y hora de la falla, la fase del proyecto, el fracaso fue encontrado en el caso de prueba que produjo el incidente, las referencias a las especificaciones u otros documentos que proporcionan información sobre el comportamiento correcto, el nombre del tester (y tal vez el revisor), el entorno de prueba y cualquier información adicional acerca de la configuración del software, sistema o medio ambiente. A veces

los testers clasifican el ámbito de aplicación, la gravedad y la prioridad del defecto, aunque a veces los gerentes o un comité de realizan ese papel para el triaje del error.

A medida que el incidente se soluciona, los administradores pueden asignar un nivel de prioridad al informe. El tablero de control de cambios o error, el comité de triaje podría documentar los riesgos, costos, oportunidades y beneficios asociados a la fijación o que no se fija el defecto. El programador, al fijar el defecto, puede capturar la causa raíz, la fase de introducción y la fase de extracción.

Después de que el defecto haya sido resuelto, administradores, programadores u otras personas pueden hacer conclusiones y recomendaciones. A lo largo del ciclo de vida del informe del incidente, desde el descubrimiento de la resolución, el sistema de seguimiento de defectos debe permitir que cada persona que trabaja en el informe de incidente pueda entrar en el estado e información de la historia.

IEEE 829 STANDARD: PRUEBA DE PLANTILLA DE INFORME DE