CASOS DE PRUEBA

Sistema de Planificación Periódica de Requerimientos Informáticos 2

Conocimiento

Clase de equivalencia

Tabla Nº1 Formulario de Casos de Prueba con uso de

Criterios de Especificación Formal, Clases de Equivalencia y Análisis de Valores Límite

6.2.3 Definición de los procedimientos de prueba

Para llevar a cabo el procedimiento de prueba, se ha determinado que las actividades de las pruebas funcionales, serán abordadas como se indica a continuación:

• Que la encargada de Testing Claudia Meléndez (T1), se ocupará de diseñar, generar, ejecutar y reportar los casos de prueba para los casos de uso de: Módulo XYZ, Módulo ABC; descritos en el Reporte de Especificación de Software (RES) versión x.y.z.

• Que la encargada de Testing Nadia Aliaga (T2), se ocupará de diseñar, generar, ejecutar y reportar los casos de prueba para casos de uso de: Módulo RST, Módulo UVW; descritos en el Reporte de Especificación de Software (RES) versión x.y.z

• Las fechas correspondientes a las actividades, se mostrarán en la tabla Nº3 de la sección 7.

6.2.4 Ejecución de los Casos de Prueba

Para la ejecución de los casos de prueba, teniendo el sistema XYZ integrado, se aplicarán las entradas descritas para cada caso de prueba generado en la sección 6.2.2, a través de las interfaces del sistema, para lo cual se deberá generar la Tabla Nº2 de Resultados Obtenidos, en donde se irá comparando los

resultados obtenidos con los esperados para identificar las posibles fallas (que ocurren cuando un programa no se comporta adecuadamente, esto quiere decir que hay un defecto en el código) y que a continuación se presenta:

Código de Caso de Prueba

Salida Esperada Salida obtenida (*)

Tabla Nº2 Tabla de Resultados Obtenidos

(*): La respuesta de la salida obtenida deberá ser el resultado de comparar la salida obtenida con la esperada: “OK” (la salida obtenida está dentro del rango previsto por la salida esperada), “falla menor” (la diferencia entre las salidas es una cuestión de formato), “falla grave” (el sistema no completó su salida o la completó pero se "cayó" después).

6.2.5 Reportar y Documentar las Pruebas

Luego de haber ejecutado todos los casos de pruebas validados, éstos se deben documentar, con el resultado de la ejecución (salida obtenida), determinando el número de cuáles pasaron satisfactoriamente, cuáles no lo hicieron y además que fallas se encontraron.

Para el completo reporte de las pruebas, se deberá generar un documento, “Informe de Reportes de Casos de Prueba a Requerimientos Funcionales”, que deberá contener:

• Título

• Fecha

• Realizado por

• Historial de versiones

• Dependiendo del criterio usado: Tabla de identificación de clases de equivalencia

• Tablas de formulario de casos de prueba, aplicando el criterio de clases de equivalencia y análisis de valores límite (tabla Nº1, de la sección 6.2.2) Tabla de Resultados Obtenidos (Tabla 2) con todos los casos de pruebas

6.2.6 Análisis de Resultados Obtenidos

Para realizar el análisis de resultados obtenidos, se hará de acuerdo a la tabla de resultados obtenidos (tabla Nº2), y se deberán sacar conclusiones de acuerdo al número de aprobaciones (resultados esperados “OK”) y fallas encontradas (resultado obtenido “falla menor” o “falla grave”).

Para el completo reporte de análisis de resultados, se deberá generar un documento que, deberá ser llamado “Informe de análisis de resultados obtenidos de Pruebas a Requerimientos Funcionales”, que deberá contener:

• ¿Cuál es el estado actual del software, en cuanto al nivel probable de calidad que alcanzó? Para esto, se debe determinar el porcentaje de salidas obtenidas con respuesta OK, las cuales se suman, obteniendo el total de nivel de satisfacción de las pruebas a requerimientos funcionales. Se espera que este porcentaje sea superior a

un 85%, de lo contrario el sistema no estaría cumpliendo con los atributos de calidad mínimos requerido por el equipo de Calidad.

• ¿Cuánto tiempo se llevaron los procesos de prueba? Se debe mencionar la cantidad de días u horas que se necesitó.

• ¿Cuán efectivo fue el proceso de prueba? (¿cuántos fallas se detectaron?) Se deberá dar el número de fallas encontradas.

• ¿Qué tipo de fallas se producen? Se debe mencionar cuántas fallas menores y graves se registraron, cuáles fueron más frecuentes

• ¿Se debe realizar el proceso de depuración? Esta interrogante se responderá en caso de haber encontrado fallas en el sistema. En caso contrario, se comunica en el informe que se ha terminado el proceso de pruebas.

La última interrogante mencionada llevará a determinar en este informe si se termina el proceso de pruebas, esto para saber si se puede dar por concluido. En caso negativo, se debe planificar el proceso de depuración dentro del informe de análisis de resultados obtenidos.

El proceso de depuración consiste en arreglar las fallas en el sistema que generaron los casos de prueba ejecutados, para esto, se debe informar al líder relacionado, de modo que éste avise al programador correspondiente. Por lo tanto, el programador relacionado, deberá depurar la falla encontrada (salida obtenida no esperada) y el ejecutor de las pruebas deberá volver a ejecutar todos los casos de prueba nuevamente (casos de prueba que no se ejecutaron satisfactoriamente, y casos que se ejecutaron satisfactoriamente). La razón de esto, es confirmar que la corrección de un defecto no introdujo un nuevo defecto. Esto se debe dejar en claro en el informe de análisis de resultados obtenidos.

7. Planificación

Se contemplan las actividades relacionadas con el plan de Pruebas, en donde se describe:

• Actividad

• Responsable, puede ser el equipo de testing (T1: Claudia Méndez y T2: Nadia Aliaga), SQA: Mariela Orrego, Líderes (Fabián López, Daniel Vásquez, Alejandra Torres, Alfonso Morris)

• Comienzo: fecha en que comienza la actividad

• Término: fecha en que termina la actividad

• Duración

Actividad Responsable Comienzo Término Duración

Casos de Prueba para Requerimientos

Funcionales: nombre de módulo 1

T1 do 05-06-

05 vi 10-06-05 6 días

Casos de Prueba para Requerimientos

Funcionales: nombre de

T2 do 05-06-

módulo 2

Informe de casos de pruebas

de Sistema T1, T2 sa 11-06- 05 sa 11-06- 05 1 día

Revisión de Informe SQA, Líderes ma14-06-

05

jue16-06- 05

3 días

Corrección de informe T1, T2 Vie17-06-

05

Vie17-06- 05

1 día

Envío de pruebas a equipo T1, T2 Sa18-06-05 Sa18-06-05 1 día

Ejecución de Casos de Prueba de Sistema Líderes,T1, T2, BD (*) ma 28-06- 05 mi 29-06- 05 2 días Informe de Reportes de

Pruebas de Sistema e Informe de análisis de resultados obtenidos T1, T2 mi 29-06- 05 mi 29-06- 05 1 día

Revisión de Reporte e informe

de análisis SQA, Líderes ju 30-06-05 ju 30-06-05

1 día

Corrección de Reporte e

informe de análisis T1, T2 ju 30-06-05 ju 30-06-05

1 día Envío de Informes de reporte y

análisis a equipo T1, T2 vi 01-07-05 vi 01-07-05

1 día

Resumen

 _{La prueba del software es un elemento crítico para la garantía de la calidad del}

software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además, esta etapa implica:

• Verificar la interacción de componentes.

• Verificar la integración adecuada de los componentes.

• Verificar que todos los requisitos se han implementado correctamente.

• Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente.

• Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.

 _{La prueba es un proceso que se enfoca sobre la lógica interna del software y las}

funciones externas. La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto

 _{Una vez generado el código fuente, es necesario probar el software para descubrir}

(y corregir) la mayor cantidad de errores posible antes de entregarlo al cliente. Su objetivo es diseñar una serie de casos de prueba que tengan una alta probabilidad de encontrar errores. Aquí es donde entran las técnicas de prueba del software. Estas técnicas proporcionan directrices sistemáticas para pruebas de diseño que 1) comprueben la lógica interna y las interfaces de todo componente del software y 2) comprueben los dominios de entrada y salida del programa para descubrir errores en su función, comportamiento y desempeño.

 _{Durante las etapas iniciales del proceso, el desarrollador realiza todas las pruebas.}

Sin embargo, a medida que avanza este proceso se irán incorporando especialistas en pruebas.