La documentación de prueba de software es el elemento vital que eleva cualquier actividad experimental al nivel de una prueba de software . [1] Organizaciones internacionales como IEEE e ISO han publicado estándares para la documentación de pruebas de software.
Estado de IEEE 829
Nota: IEEE 829-2008 ha sido reemplazado por ISO / IEC / IEEE 29119-3: 2013 . [2]
Antecedentes de IEEE 829
IEEE 829-2008 , también conocido como el estándar 829 para la documentación de pruebas de software y sistemas , era un estándar IEEE que especificaba la forma de un conjunto de documentos para su uso en ocho etapas definidas de pruebas de software y pruebas de sistemas , cada etapa produciendo potencialmente su propia tipo de documento separado. La norma especificaba el formato de estos documentos, pero no estipulaba si debían producirse todos, ni incluía ningún criterio sobre el contenido adecuado de estos documentos. Se trataba de una cuestión de juicio fuera del ámbito de la norma.
Documentos requeridos por IEEE 829
Los documentos son:
- Plan maestro de pruebas (MTP): el propósito del Plan maestro de pruebas (MTP) es proporcionar un documento general de planificación y gestión de pruebas para varios niveles de prueba (ya sea dentro de un proyecto o en varios proyectos).
- Plan de prueba de nivel (LTP): para cada LTP, es necesario describir el alcance, el enfoque, los recursos y el cronograma de las actividades de prueba para su nivel específico de prueba. Es necesario identificar los elementos que se prueban, las características que se probarán, las tareas de prueba que se realizarán, el personal responsable de cada tarea y los riesgos asociados.
- Diseño de prueba de nivel (LTD): detalla los casos de prueba y los resultados esperados, así como los criterios para aprobar la prueba.
- Caso de prueba de nivel (LTC): Especifica los datos de prueba que se utilizarán para ejecutar los casos de prueba identificados en el Diseño de prueba de nivel.
- Procedimiento de prueba de nivel (LTPr): detalla cómo ejecutar cada prueba, incluidas las condiciones previas de configuración y los pasos que deben seguirse.
- Registro de pruebas de nivel (LTL): para proporcionar un registro cronológico de los detalles relevantes sobre la ejecución de las pruebas, por ejemplo, registrar qué casos de pruebas se ejecutaron, quién los ejecutó, en qué orden y si cada prueba pasó o falló.
- Informe de anomalías (AR): para documentar cualquier evento que ocurra durante el proceso de prueba que requiera investigación. Esto puede denominarse informe de problema, incidente de prueba, defecto, problema, anomalía o error. Este documento se nombra deliberadamente como un informe de anomalías y no como un informe de fallas. La razón es que una discrepancia entre los resultados esperados y reales puede ocurrir por varias razones distintas a una falla en el sistema. Estos incluyen que los resultados esperados sean incorrectos, que la prueba se ejecute incorrectamente o inconsistencias en los requisitos, lo que significa que se podría realizar más de una interpretación. El informe consta de todos los detalles del incidente, como los resultados reales y esperados, cuándo falló y cualquier evidencia de respaldo que ayude a su resolución. El informe también incluirá, si es posible, una evaluación del impacto de un incidente en las pruebas.
- Informe de estado de prueba de nivel intermedio (LITSR): para resumir los resultados intermedios de las actividades de prueba designadas y, opcionalmente, proporcionar evaluaciones y recomendaciones basadas en los resultados para el nivel de prueba específico.
- Informe de prueba de nivel (LTR): para resumir los resultados de las actividades de prueba designadas y proporcionar evaluaciones y recomendaciones basadas en los resultados una vez finalizada la ejecución de la prueba para el nivel de prueba específico.
- Informe de prueba maestro (MTR): para resumir los resultados de los niveles de las actividades de prueba designadas y proporcionar evaluaciones basadas en estos resultados. Este informe puede ser utilizado por cualquier organización que utilice el MTP. Un informe de gestión que proporciona cualquier información importante descubierta por las pruebas realizadas, e incluye evaluaciones de la calidad del esfuerzo de prueba, la calidad del sistema de software bajo prueba y estadísticas derivadas de los informes de anomalías. El informe también registra qué pruebas se realizaron y cuánto tiempo tomó, para mejorar cualquier planificación de pruebas futuras. Este documento final se utiliza para indicar si el sistema de software bajo prueba es apto para su propósito de acuerdo con si ha cumplido o no con los criterios de aceptación definidos por las partes interesadas del proyecto.
Uso de IEEE 829
El estándar forma parte del programa de formación de la Fundación ISEB y Certificados de Practicante en Pruebas de Software promovidos por la British Computer Society . ISTQB , tras la formación de su propio plan de estudios basado en ISEB 's y la Alemania de ASQF programas de estudio, también adoptó IEEE 829 como patrón de referencia para la documentación de software y sistema de prueba.
El Dr. David Gelperin y el Dr. William C. Hetzel desarrollaron la metodología del Proceso de evaluación y prueba sistemática (STEP) para implementar el estándar IEEE-829 original para la documentación de pruebas de software. [3]
Referencias
- ^ "Documentación de prueba de software: ¿cómo debería verse la documentación de prueba?" . LOS-EXPERTOS-EN-SOFTWARE . Consultado el 18 de enero de 2017 .
- ^ "Informe de estado de proyectos y productos IEEE" . Standards.ieee.org . Consultado el 13 de octubre de 2017 .
- ^ Rick D. Craig; Stefan P. Jaskiel (2002). Pruebas de software sistemáticas . Casa Artech. pag. 4. ISBN 978-1-58053-792-6.
enlaces externos
- IEEE Std 829-2008 , estándar IEEE para documentación de pruebas de software y sistemas
- BS7925-2 , estándar para pruebas de componentes de software