DOCUMENTACION DEL DISEÑO DE PRUEBAS

Plan de Pruebas
Señalar:
• El enfoque
• Los recursos
• El esquema de actividades de prueba
• Los elementos a probar
• Las características
• Las actividades de prueba
• El personal responsable
• Los riesgos asociados



Estructura Fijada en el estándar
• Identificador único del documento (para la gestión de
configuración).
• Introducción y resumen de elementos y características a probar.
• Elementos software que se van a probar (p. ej., programas o módulos).
• Características que se van a probar.
• Características que no se prueban.
• Enfoque general de la prueba (actividades, técnicas, herramientas, etc.).
• Criterios de paso/fallo para cada elemento.
• Criterios de suspensión y requisitos de reanudación.
• Documentos a entregar (como mínimo, los descritos en el estándar).
• Actividades de preparación y ejecución de pruebas.
• Necesidades de entorno.
• Responsabilidades en la organización y realización de las pruebas.
• Necesidades de personal y de formación.
• Esquema de tiempos (con tiempos estimados, hitos, etc.).
• Riesgos asumidos por el plan y planes de contingencias para cada riesgo.
• Aprobaciones y firmas con nombre y puesto desempeñado

Especificación del Diseño de Pruebas
􀁺 Objetivo: Especificar los refinamientos
necesarios sobre el enfoque general reflejado
en el plan e identificar las características que
se deben probar con este diseño de pruebas.
􀁺 Estructura Fijada por el estándar:
• Identificador (único) para la especificación. Proporcionar también una referencia del plan asociado (si existe).
• Características a probar de los elementos software (y
combinaciones de características).
• Detalles sobre el plan de pruebas del que surge este diseño, incluyendo las técnicas de prueba específica y los métodos de análisis de resultados.
• Identificación de cada prueba:
• Identificador.
• Casos que se van a utilizar.
• Procedimientos que se van a seguir.
• Criterios de paso/fallo de la prueba (criterios para determinar si una característica o combinación de características ha pasado con éxito la prueba o no).

Ejecución de las pruebas



Documentación de la Ejecución de las pruebas



Historico de Pruebas
Documenta todos los hechos relevantes ocurridos durante la ejecución de las pruebas.
1.-Informe de Incidente:
2.-Documenta cada incidente (p. ej., una interrupción en las pruebas debido a un corte de electricidad, bloqueo del teclado, etc.)
3.-Ocurrido en la prueba y que requiera una posterior investigación.
4.-Informe resumen:
Resume los resultados de las actividades de prueba (las reseñadas en el propio informe) y aporta una evaluación del software, basada en dichos resultados.

RELACION ENTRE DEFECTO, FALLA Y ERROR

Error (error):

Es una equivocación cometida por un desarrollador. Algunos ejemplos de errores son: un error de tipeo, una malinterpretación de un requerimiento o de la funcionalidad de un método. El estándar 829 de la IEEE coincide con la definición de diccionario de error como “una idea falsa o equivocada”. Por ende un programa no puede tener o estar en un error, ya que los programas no tienen ideas; las ideas las tienen la gente.

Defecto (fault, defect):

Un error puede conducir a uno o más defectos. Un defecto se encuentra en un artefacto y puede definirse como una diferencia entre la versión correcta del artefacto y una versión incorrecta. De nuevo coincide con la definición de diccionario, “imperfección”. Por ejemplo, un defecto es haber utilizado el operador “<” en vez de “<=“.

Falla (failure):

En terminología IEEE, una falla es la discrepancia visible que se produce al ejecutar un programa con un defecto, respecto a la ejecución del programa correcto.

Es decir,una falla es el síntoma de un defecto.

DEFINICIONES DE PRUEBAS DE SOFTWARE

Pruebas (test): «una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto»

Caso de prueba (test case): «un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular»

Defecto (defect, fault, «bug»): «un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa»Falla: Puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación.

Fallo (failure): «La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados»

Error (error): tiene varias acepciones: La diferencia entre un valor calculado, observado o medio y el valor verdadero, especificado o teóricamente correcto.

Verificación: El proceso de evaluación de un sistema (o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase.

Validación: El proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario.