Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Norma IEEE 829 - 2008

Para la Documentación de Pruebas de Software y Sistema
by

jose luis contreras

on 21 November 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Norma IEEE 829 - 2008

1.alcance Esta norma se aplica a todos los sistemas basados en software. Se aplica a los sistemas y programas que se están desarrollando.

Esta norma identifica los aspectos del sistema, los procesos de prueba y la dirección de las tareas en el sistema de determinación y corrección de software y otros atributos (por ejemplo, la integridad, precisión, consistencia y capacidad de prueba), y la documentación pertinente de ensayo resultante. Presentado por:
Helver Carreño
José Luis Contreras Norma IEEE 829
para la Documentación
de Pruebas de
Software y Sistema De acuerdo con el estándar IEEE Std. 829 , los documentos relacionados con el diseño de pruebas son: El estándar IEEE 829 proporciona una base estándar para la documentación del proceso de pruebas, permitiendo plasmar todos los aspectos clave de las pruebas. El propósito de las pruebas basadas en los sistemas es ayudar a la organización de desarrollo de la calidad de construcción en el software y el sistema durante los procesos de ciclo de vida y para validar que la calidad se logró. Los procesos de prueba determina si los productos de desarrollo de una actividad dada se ajustan a los requisitos de una actividad y si el sistema y / o software satisface su uso previsto y las necesidades del usuario. 2.procesos de prueba Cada proceso tiene una o más actividades de apoyo que son a su vez ejecutada por una o más tareas. Este es un método de arriba hacia abajo para determinar las tareas que se requieren. Una vez que cada tarea ha sido identificado, sus entradas y salidas necesarias resultantes pueden ser identificados. En el caso de esta norma, las entradas y salidas de determinar qué documentación de pruebas son necesarias. 2.1.Actividad de gestión de pruebas Esta actividad monitorea y evalúa todos los resultados de las pruebas. Esta actividad revisa continuamente las pruebas, genera el plan de mediano plazo si así lo requiere el nivel de integridad.
Según corresponda para el nivel de integridad seleccionado, estas tareas mínimas recomendadas: Tareas Mínimas: a) Genera el plan de pruebas Master
b) Realiza revisión por la dirección del esfuerzo de prueba
c) Realiza revisión por la dirección y el apoyo revisión técnica
d) Las interfaces con los procesos organizativos y de reparto
e) Identificar oportunidades de mejora de procesos, incluidas las lecciones aprendidas en el desarrollo de las pruebas 2.2.Proceso de adquisición comienza con la definición de la necesidad de adquirir un sistema, producto software o servicio software. El proceso continúa con la preparación y emisión de una solicitud de propuesta y con la selección de un proveedor. Termina con la gestión del proceso de adquisición a través de la aceptación del sistema, producto software o servicio software. 2.3.Proceso de suministro se inicia con la oferta o bien la decisión de preparar una propuesta para responder a una solicitud de propuesta adquirente, o bien mediante la firma y celebración de un contrato con el comprador para dotar al sistema basado en software, producto software o servicio. 2.4.Proceso de desarrollo desarrollo consiste en las actividades y tareas del grupo de desarrollo. El proceso de desarrollo abarca las actividades de desarrollo de análisis de requerimientos, diseño, codificación, integración de componentes, pruebas, instalación y aceptación, relacionado con el software o el producto de sistema basado en software. 2.5.Proceso de operación comprende el funcionamiento del producto de software y soporte operativo a los usuarios. La actividad de operación realiza pruebas de funcionamiento, operación del sistema y soporte al usuario. 2.6 Proceso de mantenimiento se activa cuando el sistema basado en software o producto de software experimenta modificaciones en el código y la documentación asociada causada por un problema, una necesidad de mejora, o la adaptación. 3. Prueba temas de la documentación
de contenidos que se abordarán se define como de tomar una decisión en cuanto a si un tema contenido se debe documentar con anterioridad a la ejecución de la prueba, documentado posterior a la prueba de ejecución, no documentado (dirigida por el proceso) , o no incluido. "Incluido" significa que o bien la información está presente o no es una referencia a donde existe. 4.Plan Maestro de prueba proporciona una planificación global de la prueba y de gestión de documentos de prueba para varios niveles de prueba (ya sea dentro de un proyecto o varios proyectos).
Establece objetivos para cada parte, los tiempos y recursos, identifica riesgos, normas de trabajo que definen los controles de esfuerzo. 4.1 Introducción se identifica el documento y lo coloca en el contexto del ciclo de vida de proyectos específicos. Es en esta sección es que el esfuerzo de prueba completo se describe, incluyendo la organización del ensayo, el programa de ensayo, y el esquema de integridad. 4.2 Los detalles del plan de pruebas Maestro se describen los procesos de prueba, los requisitos de documentación, pruebas y requisitos de presentación de informes de prueba para el esfuerzo de la prueba entera. 4.3 General se incluye un glosario de términos y acrónimos. También se describe la frecuencia y el proceso por el cual se cambia la MTP y línea base.
También puede contener un cambio de página que contiene el historial de los cambios
(fecha, la razón para el cambio, y que inició el cambio). 5. Nivel Plan de Pruebas Especifica el alcance, enfoque, los recursos y el calendario de las actividades de prueba de su nivel específico de la prueba. Identifica los elementos que se están probando, las características para ser probadas, las tareas de pruebas a realizar, el personal responsable de cada tarea, y el riesgo asociado. 5.1.Los detalles de este nivel de
plan de pruebas describe los elementos específicos que se evalúan en el nivel designado y proporciona una matriz de rastreabilidad de prueba que vincula los elementos a ensayar con los requisitos. 6.Nivel de Diseño de los ensayos
(Level Test Design) especifica los ajustes finos del enfoque de prueba e identifica las características para ser analizadas por este diseño y las pruebas asociadas. 6.1. Introducción se identifica el emisor y los detalles de la emisión. Incluye aprobaciones requeridas y el estado (PROYECTO / FINAL) del documento. Es aquí que el alcance se describe y se identifica referencias. 7.Nivel de casos de prueba definir (con un nivel de detalle apropiado) la información necesaria en lo que respecta a las entradas y salidas del software o el sistema basado en software se está probando. 8.Nivel de Procedimiento de la Prueba El propósito es especificar los pasos para ejecutar un conjunto de casos de prueba o, más en general, los pasos utilizados para ejercer un producto de software o software basado en elemento del sistema con el fin de evaluar un conjunto de características. 9.Nivel de registro de prueba Proporciona un registro cronológico de datos pertinentes sobre la ejecución de las pruebas. En una herramienta automatizada puede capturar toda o parte de esta información. 10.Anomalía Informe El propósito es documentar cualquier evento que se produce durante el proceso de prueba que requiere investigación. Esto puede ser llamado un problema, el informe de incidente de prueba, defecto, problema, anomalía o error. 11.Nivel de prueba provisional
Informe de situación Resume los resultados de las actividades de control designados y opcionalmente para proporcionar evaluaciones y recomendaciones basadas en los resultados.
Se acostumbra a sustituir la palabra "nivel" en el título del documento con el nombre de la organización para el nivel de prueba en particular. 12.Nivel Informe de prueba (LTR) resume los resultados de las actividades de control designados y proporciona evaluaciones y recomendaciones basadas en los resultados. Se acostumbra a sustituir la palabra "nivel" en el título del documento con el nombre de la organización para el nivel de prueba en particular, por ejemplo, informe de prueba de aceptación. Hay un LTR para cada nivel de prueba definida por la organización o proyecto. 13.Maestro informe de prueba resumir los resultados de los niveles de las actividades de pruebas designadas y para proporcionar evaluaciones basadas en estos resultados. Conclusiones y recomendaciones Ofrecer conclusiones y / o recomendaciones sobre la aceptación del producto entregado.

Describir las lecciones aprendidas y los cambios resultantes en la práctica que fueron descubiertos durante la realización de esta prueba. Esta norma establece los criterios recomendados mínimos para los procedimientos de ensayo, actividades y tareas. Niveles de integridad Un nivel de integridad es una indicación de la importancia relativa de software (o característica del software, componente o prueba de nivel) para sus grupos de interés, las establecidas por el conjunto seleccionado de atributos tales como la complejidad, la evaluación de riesgos, el nivel de seguridad, integridad de los datos, el rendimiento deseado, la fiabilidad, la calidad, coste, tamaño, y / o otras características únicas del software.
Full transcript