Gestión de pruebas (K3) - Gestión de Incidencias (K3).

Objetivos:

1. Reconocer el contenido de un informe de incidencias de conformidad con la "Norma para la documentación de prueba de software" (IEEE Std 829-1998) (K1).
2. Redactar un informe de incidencias sobre la observación de un fallo durante el proceso de pruebas (K3)

Términos: Registro de incidencia, gestión de incidencias, informe de incidencias..

Antecedentes.

Dado que uno de los objetivos de las pruebas es la detección de defecto, las discrepancias entre los resultados reales y los resultados esperados deben registrarse como incidencias.
Todas las incidencias deben ser investigadas, ya que algunas pueden constituir defectos. A continuación, se define las acciones adecuadas para eliminar las incidencias y los defectos.
Las incidencias y los defectos se rastrean desde su identificación y clasificación hasta la corrección y confirmación de su solución. Con vistas a gestionar todas las incidencias hasta su compleción, la organización , debe establecer un proceso de gestión de incidencias y normas para su clasificación.
Las incidencias pueden surgir durante el desarrollo, la revisión, las pruebas o el uso de un producto de software. Asímismo, pueden surgir por problemas en el código o en el sistema de funcionamiento, o en cualquier tipo de documentación que incluya requisitos, documentos de desarrollo, documentos de prueba e información de usuario, como guías de ayuda o instalación.
Los informes de incidencias tienen los siguientes objetivos:

• Facilitar feedback sobre el problema a los desarrolladores y demás partes implicadas permitiendo su identificación, aislamiento y corrección, según proceda.
• Proporcionar a los líderes de prueba un medio de seguimiento de la calidad del sistema probado y del progreso de las pruebas.
• Aportar ideas para la mejora del proceso de pruebas.

El informe de incidencias pueden incluir los siguientes detalles:

• fecha de expedición, organización emisora y autor.
• Resultados esperados y resultados reales.
• Identificación del elemento de prueba (elemento de configuración) y entorno.
• Proceso del ciclo de vida del software o del sistema en el que se ha observado la incidencia.
• Descripción de la incidencia para permitir su reproducción y resolución, incluyendo registros, volcados de bases de datos o pantallazos.
• Alcance do grado de impacto en los intereses de las partes interesadas.
• Gravedad del impacto en el sistema.
• Urgencia/prioridad de su corrección.
• Estado de la incidencia (por ejemplo, abierta, diferida, duplicada, esperando corrección, corregida esperando la repetición de las pruebas, cerradas).
• Conclusiones, recomendaciones y autorizaciones.
• Aspectos globales, como otras áreas que pueden verse afectadas por un cambio derivado de la incidencia.
• Historial del cambio, como la secuencia de acciones adoptadas por los miembros del equipo de proyecto por lo que respecta a la incidencia para aislarla y confirmarla como corregida.
• Referencias, incluyendo la identidad de la especificación de caso de prueba que puso de manifiesto el problema.

La estructura de los informes de incidencias se aborda en la "Norma para la documentación de prueba de software" (IEEE Std 829-1998). 

Pregunta de examen:

31 What information need not be included in a test incident report:
a) how to fix the fault-->NOK
b) how to reproduce the fault-->OK
c) test environment details-->OK
d) severity, priority-->OK
e) the actual and expected outcomes-->OK

31 ¿Qué información no debe figurar en un informe del incidente de prueba :
a) cómo arreglar el fallo-->NOK
b ) la forma de reproducir el fallo-->si deben ir
c ) detalles del entorno de prueba-->si deben ir
d ) la gravedad , la prioridad--->si deben ir
e) los resultados reales y esperados--> si deben ir