• Author / Uploaded
• Joseph Zenboss Condor Balbin

Citation preview

Plan de Pruebas

Versión: x.y.z

Plan de Pruebas Versión [Nombre del proyecto]

2

Plan de Pruebas

Versión: x.y.z

HISTORIAL DE REVISIONES

Versión

Autor

Descripción

Fecha de Elaboración

Fecha de Revisión

Revisado por

3

Plan de Pruebas

Versión: x.y.z

Contenido 1.

Introducción..........................................................................................................5 1.1 1.2

2.

Definiciones, Acrónimos y Abreviaturas....................................................................................5 Documentos Relacionados........................................................................................................... 5 Objetivo................................................................................................................................................ 5

3.

Alcance.................................................................................................................................................. 5 3.1 3.2

Dentro del Alcance......................................................................................................................... 6 Fuera del Ámbito............................................................................................................................ 6

4.

Roles y Recursos................................................................................................................................. 6

5.

Técnica a utilizar................................................................................................................................. 6

6.

Enfoque de las Pruebas...................................................................................................................... 6

6.1 Pruebas Funcionales........................................................................................................................... 6 6.2 Actividades................................................................................................................................................................................................ 6 6.2.1Diseño de los Casos de Prueba.................................................................................................................................................... 7 6.2.2Generación de los Casos de Prueba........................................................................................................................................... 7 6.2.3Definición de los procedimientos de prueba......................................................................................................................... 8 6.2.4Ejecución de los Casos de Prueba.............................................................................................................................................. 8 6.2.5Reportar y Documentar las Pruebas........................................................................................................................................ 9 6.2.6 Análisis de Resultados Obtenidos............................................................................................................................................. 9 7.

Planificación........................................................................................................................................ 10

4

1.

Introducción [Describa de manera breve el contenido del documento orientando la descripción hacia la utilidad que se quiere conseguir.] [El presente documento describe el plan de pruebas de sistema, esto abarca la metodología, en donde se especifican métodos, técnicas y forma en que se diseñan, ejecutan, evalúan y reportan los resultados de las pruebas de sistema Las pruebas de sistema a desarrollar, luego de leer este plan, se ejecutan en cuanto se ha finalizado con las pruebas de Integración, ya que se debe tener el sistema completo para poner en práctica las pruebas de sistema. Luego de realizar las pruebas, se verificará si el sistema XYZ cumple con los requisitos exigidos por el usuario, en los cuales se debiera obtener los resultados esperados, de no ser así, se determina que se han encontrado errores que habrá que reportar a los desarrolladores] 1.1 Definiciones, Acrónimos y Abreviaturas

1.2 Documentos Relacionados Título Reporte de Especificación de Software

2.

Fecha 24 de enero de 2011

Identificador del documento RES v2.0

Objetivo [Describa de manera breve el propósito que se pretende alcanzar con la aplicación del plan de pruebas.] El documento tiene como objetivo describir el plan a seguir para realizar las pruebas al Sistema, con lo cual se especifican etapas a seguir para diseñar, generar, definir procedimientos, ejecutar, evaluar y reportar los resultados obtenidos de las pruebas. Al diseñar y generar las pruebas, éstas se validarán con las personas calificadas para ello, para luego ejecutarlas y tomar los resultados obtenidos. Finalmente los resultados se evaluarán y reportarán. Las pruebas del sistema tienen como objetivo ejercitar el sistema comprobando la integración total del sistema, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen.

3.

Alcance [Describa de manera breve el alcance de las pruebas descritas en el plan de pruebas.] Las pruebas de sistema a realizar, serán pruebas funcionales sobre las funciones del sistema, a partir de las condiciones de entrada y evaluando los resultados obtenidos. No es necesario conocer la lógica del programa, únicamente la funcionalidad que debe realizar. Para probar correctamente el sistema, las pruebas se realizan basándose en los requerimientos establecidos por el usuario del sistema

3.1 Dentro del Alcance Se contemplan las siguientes actividades para el proceso de desarrollo de pruebas Funcionales:  Diseño de casos de prueba  Generación de casos de prueba  Definición de los procedimientos de la prueba  Ejecución de pruebas  Reportar y documentar pruebas  Análisis de resultados obtenidos  Los módulos y funciones a ser probados serán:  Módulo 1  Función 1  Función 2  Módulo 2  Función 1  Función 2 3.2 Fuera del Ámbito Indicar que módulos no serán objeto de la prueba

4.

Roles y Recursos Listar los roles y recursos asignados al proyecto RECURSOS HUMANOS Rol

5.

Mínimos recursos recomendados

Gestor de prueba

1

Diseñador de prueba

3

Probador

3

Responsabilidades específicas o comentarios Proporcionar una gestión adecuada. Responsabilidades:  Proporcionar una dirección técnica.  Adquirir los recursos apropiados.  Informar de la gestión. Identificar, priorizare implementar los casos de prueba. Responsabilidades:  Generar el Plan de pruebas.  Diseñar los Casos de prueba.  Evaluar el esfuerzo de prueba. Ejecutar las pruebas. Responsabilidades:  Ejecutar pruebas.  Recuperar los errores.  Documentar los defectos.

Recurso

Nombre del recurso (probador)

Nombre del recurso (probador)

Nombre del recurso (probador)

Técnica a utilizar La técnica a utilizar para las pruebas de sistema son las de Caja Negra.

6.

Enfoque de las Pruebas Los tipos de pruebas que se realizarán al software son:

6.1

Pruebas Funcionales Están enfocadas a asegurar que el software realiza correctamente todas las funciones que se han detallado en los requerimientos dados por el usuario. Se realizan pruebas para cada caso de uso y cada una de las actividades a desarrollar se describe en la sección 6.2

6.2

Actividades De acuerdo a lo establecido en la sección 3.1., las actividades serán: 6.2.1

Diseño de los Casos de Prueba Para diseñar los casos de prueba de sistema, se identifica la técnica de caja negra descrita en la sección 5. Para confeccionar los casos de prueba con la técnica Caja Negra, ésta provee distintos métodos. Los que se ocuparán son los siguientes:   

6.2.2

A partir de especificaciones formas de casos de uso. Particiones de Equivalencia (para condiciones de entrada de tipo valor, rango de valores, miembro de un conjunto y lógica). Análisis de Valores Límite (para condiciones de entrada de rango de valores, miembro de un conjunto y lógica)

Generación de los Casos de Prueba En la generación o creación de los casos de prueba, se representan los datos que se utilizarán como condiciones de entrada para ejecutar el software a probar. En concreto, los casos de prueba determinan un conjunto de entradas, condiciones de ejecución y resultados esperados para un caso de uso en particular. La técnica de caja negra proporciona distintos criterios para generar los casos de prueba. A continuación, en las tablas Nº 1 y 5 se presenta una tabla de formulario de casos de prueba para cada criterio determinado. En general, para la generación de todos los casos de prueba se debe tener lo siguiente:          

Aplicativo: Nombre del aplicativo bajo pruebas. Requerimiento: Código del Requerimiento Funcional asociado al CUS que se probará. Proceso: Módulo en el que reside el CUS que se probará. Caso de Uso: Código y nombre del CUS que se probará Responsable: Nombre del responsable de ejecución de la prueba. Pre-Condiciones: Que pueden tener relación con la precondición del casos de uso. Propósito: Objetivo del caso de prueba. Escenario: Código y nombre del escenario que será desarrollado por el caso de prueba. Actividad: Descripción de las acciones para ejercitar el caso de prueba, a partir de las condiciones de entrada (que son las entradas del sistema). Clase de equivalencia: Códigos de las clases de equivalencia que serán utilizados en la prueba.



Resultado esperado: Es el resultado que producirá el software al ejecutar dicho caso, lo que es necesario para detectar una posible falla en el programa, además de observaciones en caso necesario.

A continuación se presentan los formularios para los casos de pruebas

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:

6.2.4



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.

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 Casos de Prueba para Requerimientos Funcionales: nombre de módulo 1 Casos de Prueba para Requerimientos Funcionales: nombre de módulo 2 Informe de casos de pruebas de Sistema Revisión de Informe Corrección de informe

Responsable

Comienzo

Término

T1

do 05

05-06-

vi 10-06-05

T2

do 05

05-06-

T1, T2 SQA, Líderes T1, T2

vi 10-06-05

sa 11-06-05

sa 11-06-05

ma14-0605 Vie17-0605

jue16-0605 Vie17-0605

Duración 6 días 6 días 1 día 3 días 1 día

Envío de pruebas a equipo T1, T2 Sa18-06-05 Sa18-06-05 Ejecución de Casos de Líderes,T1, ma 28-06mi 29-06Prueba de Sistema T2, BD (*) 05 05 Informe de Reportes de Pruebas de Sistema e Informe mi 29-06- mi 29-06T1, T2 de análisis de resultados 05 05 obtenidos Revisión de Reporte e informe SQA, Líderes ju 30-06-05 ju 30-06-05 de análisis Corrección de Reporte e T1, T2 ju 30-06-05 ju 30-06-05 informe de análisis Envío de Informes de reporte y T1, T2 vi 01-07-05 vi 01-07-05 análisis a equipo Tabla Nº3 de Actividades del plan de pruebas de sistema

1 día 2 días 1 día

1 día 1 día 1 día