• Author / Uploaded
• Wilson Anthony Lazo Tapia

Citation preview

Plan de Pruebas Versión 1.0

TuBodeguita

________________________________________________________________________________

Plan de Pruebas Versión: 1.0

TuBodeguita

HISTORIAL DE REVISIONES

Versión

1.0

Autor

Descripción

Lazo tapia Wilson Anthony

Versión preliminar como propuesta de desarrollo

Fecha de Elaboració n 10/06/2019

Fecha de Revisión 16/06/2019

Revisado por Henry Joe Wong , Urquiza

3

Plan de Pruebas Versión: 1.0

TuBodeguita

Contenido 1.

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

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

2.

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 La presente Especificación de requerimientos de software (TuBodeguita) del sistema a construir surge para ser un conjunto de información necesaria que ayuda a los desarrolladores del software a analizar y entender todos los requisitos y requerimientos que nuestro cliente desea , de la misma forma como este constituye un informe útil para que el cliente del producto final describa lo que el realmente desea obtener, y de esta manera lograr tener un documento necesario cuya información en el futuro servirá para el desarrollo del software, es decir en la codificación correcta del mismo. Se describirá, métodos, técnicas y forma en que se diseña, ejecutan, evalúan y reportan los resultados de las pruebas. Permitir establecer las bases de acuerdo entre usuarios en lo que al proyecto de software se refiere. Ayudar a los usuarios finales del software a entender exactamente qué es lo que el cliente de software desea es el propósito de este informe. 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 “tubodeguita” 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 PROTOTIPO: Diseño para las pruebas SQA: Aseguramiento de la calidad del software CUS05: Caso de uso registrar producto CUS06: Caso de uso Buscar producto CUS07: Caso de uso Actualizar producto CUS08: Caso de uso Eliminar Producto 1.2 Documentos Relacionados Título Reporte de Especificación de Sistema TuBodeguita

2.

Fecha 16 de JUNIO de 2019

Identificador del documento v1.0

Objetivo 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. se elabora con el fin de especificar qué elementos o componentes se realizará un proceso de evaluación y verificación de los requerimientos funcionales y no funcionales. Mediante este plan de pruebas, se va obtener información sobre los errores defectos o fallas que tiene el prototipo, así se realizaran las correcciones pertinentes. 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. Validar el diseño del sistema TuBodeguita, mediante la evaluación de cada uno de los casos de usos determinados y funcionalidades estipuladas en cada caso de uso del diseño del sistema. 5

3.

Alcance 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 Actividades para el proceso de desarrollo de pruebas Funcionales: 1.Modulo para registro del producto (CUS05) DESCRIPCIÓN: Este caso de uso permite al actor registrar información de los productos del sistema.

Flujo:       

Ir a la ruta del de Mantenimiento de Producto El sistema muestra la pantalla CUS05-A, los campos están con sus valores iniciales y la grilla contiene los datos filtrados según estos valores. El usuario hace clic en el botón Nuevo El sistema muestra la pantalla CUS05 -B, los campos están con sus valores iniciales. El usuario ingresa los campos obligatorios Nombre, Precio y selecciona una categoría. El usuario hace clic en el botón Guardar. El sistema validará que se hayan ingresado los campos obligatorios.

2.Modulo Buscar Producto (CUS06) DESCRIPCIÓN: Este caso de uso permite al actor filtrar información de los productos del sistema.

Flujo:   

Ir a la ruta del de Mantenimiento de Producto El sistema muestra la pantalla CUS06-A, los campos están con sus valores iniciales y la grilla contiene los datos filtrados según estos valores. El usuario hace clic en el botón Filtrar.

3.Modulo Actualizar Producto (CUS07) DESCRIPCIÓN: Este caso de uso permite al actor actualizar información de los productos del sistema.

Flujo: 6

      

Empieza luego del ítem 3 del flujo básico de CUS06 El usuario selecciona de la grilla un producto que desea editar. El usuario hace clic en el botón Editar de Mantenimiento de Producto. El sistema muestra la pantalla CUS07-A, con los campos obligatorios llenados con la información del producto seleccionado. El usuario ingresa los campos obligatorios Nombre, Precio y selecciona una categoría. El usuario hace clic en el botón Guardar. El sistema validará que se hayan ingresado el campo obligatorio.

4.Modulo eliminar producto (CUS08) DESCRIPCIÓN: Este caso de uso permite al eliminar información de los Productos del sistema .

Flujo:    

Empieza luego del ítem 3 del flujo básico de CUS06. El usuario selecciona de la grilla un producto que desea eliminar. El usuario hace clic en el botón Eliminar. El sistema validará que se haya seleccionado una categoría para eliminar.

3.2 Fuera del Ámbito Los módulos o tareas que quedan fuera del ámbito serian el hardware que damos uso para realizar el plan de pruebas del prototipo. Así también se incrementa el grado de usabilidad del sistema y el usuario final. El hardware utilizado debe contar con los requerimientos mínimos para que funcione el sistema de manera adecuada, el software debe poseer una apariencia agradable y fácil de utilizar para el usuario final. Tampoco incluye la prueba de estrés.

4.

Roles y Recursos Listar los roles y recursos asignados al proyecto

7

RECURSOS HUMANOS Rol

Mínimos recursos recomendados

Responsabilidades específicas o comentarios Proporcionar una gestión adecuada. Responsabilidades:

Gestor de prueba

 1

 

Diseñado r de prueba

Proporcionar técnica. Adquirir apropiados.

una los

dirección recursos

  

Generar el Plan de pruebas. Diseñar los Casos de prueba. Evaluar el esfuerzo de prueba.

Ejecutar las pruebas. Responsabilidades: Probador

3

  

Realizar la planificación y administración de los recursos para las pruebas

Informar de la gestión.

Identificar, priorizare implementar los casos de prueba. Responsabilidades: 3

Recurso

Ejecutar pruebas. Recuperar los errores. Documentar los defectos.

Técnicas de pruebas vistas. Mantener la arquitectura de automatización de pruebas. Realizar la configuración de pruebas. Evaluar los enfoques de pruebas

Implementar la mejor prueba. Implementación de pruebas individuales. Preparación y ejecución de pruebas. Análisis de los errores de ejecución

8

5.

Técnica a utilizar La técnica a utilizar para las pruebas de sistema son las de Caja Negra. 1.Pruebas de Funcionalidad: Es el tipo de prueba más básico que existe y se puede automatizar utilizando diferentes herramientas del tipo record & play como son el Selenium IDE, Rational FunctionalTester, entre otros. Existen diferentes tipos de pruebas de funcionales, entre las más importantes figuran: • Pruebas de integración • Pruebas de usabilidad • Pruebas de interfaz •

Pruebas de regresión

2.Pruebas de Interfaz de usuario: prueba funcional 3.Pruebas de rendimiento: Analizan diferentes factores de rendimiento del software en diferentes escenarios de uso, como por ejemplo (ISTQB, 2014): • tiempos de respuesta • consumo de recursos • habilidad de soportar cargas Mayormente automatizadas con scripts y herramientas como: • Web Application Stress Tool (Microsoft) • Rational Performance Tester • JMeter 4.Pruebas de carga: prueba no funcional 5.Pruebas de seguridad : Prueban que el software no sea víctima de ataques cibernéticos. Están basadas en modelos de amenazas de software. Usualmente se realizan usando métodos de caja blanca y caja negra (ISTQB, 2014).Usan depuradores, scripts y diferentes herramientas como: • Wireshark - Monitorea paquetes de diferentes protocolos de red. • Burp Proxy - Proxy de HTTP que permite modificar los paquetes de red HTTP que envía y recibe un cliente web como un browser web. 6.Prueba de Robustez: Las pruebas de robustez (ISTQB, 2014) son las encargadas de validar si el aplicativo es capaz de soportar entradas de datos de manera incorrecta o instrucciones incorrectas. Por ejemplo, en los campos donde debemos ingresar número ingresamos textos, operadores matemáticos, entre otros.

9

7. Pruebas de desempeño: Las pruebas de desempeño (ISTQB, 2014) son usadas para validar que una aplicación soporte la cantidad de peticiones concurrentes que se acordó con el cliente final. Por ejemplo, si tenemos una aplicación de matrícula de alumnos y en dicha universidad hay mil alumnos, no significa que todos van a hacer peticiones al mismo tiempo. 8. Pruebas de confiabilidad: Las pruebas de confiabilidad (Microsoft, 2017) consiste en probar la aplicación de manera total antes de poner a producción la aplicación. Debido a que existen varios flujos de una aplicación que se tiene que probar, puede darse el caso de que no se prueben todos los caminos, pero sería recomendable probar las funcionalidades que son del Core del negocio.

6.

Enfoque de las Pruebas

Los tipos de pruebas que se realizarán al software son: 6.1

Pruebas Funcionales

Es para que el software funcione adecuadamente. Se realizan pruebas para cada caso de uso y cada una de las actividades 6.2

Actividades

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. 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:   

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)

1.Pruebas de funcionalidad:

Objetivos: Probar la operatividad con las funciones requeridas, a la cual incluye el desplazamiento en el Prototipo, el ingreso de datos, procedimientos y validación de campo. Técnicas: Ejecutar los casos de uso, flujo, utilizando datos ingresados previamente con la validación del campo. La validación se puede determinar de la siguiente forma:  El ingreso de las entradas se puede visualizar y es lo esperado, porque se usó una entrada o dato valido.

10

 Cuando se utilizada entradas o datos no válidos, se muestra los mensajes de error o advertencia y por consiguiente no se realiza el ingreso. Criterios de finalización: Sean ejecutado todas las pruebas requeridas de los casos de uso del sistema TuBodeguita.

2.Pruebas de interfaz de usuario: Objetivos: Se puede visualizar:  El desplazamiento del prototipo cumple con las funciones requeridas en el interfaz, para el óptimo desenvolvimiento al momento de interactuar con el usuario. Técnica: Realiza las modificaciones de prueba en el prototipo para cada caso de uso implementada para el usuario, para sí reducir y corregir errores de interfaz. Criterio de finalización: La interfaz se visualiza en una forma agradable, optima y aceptable.

3.Prueba de Rendimiento: Objetivos:Rendimiento óptimo al momento de procesar la información. Técnica: Para generar la cantidad de procesamiento adecuada, se realizarán deferentes números de accesos a la máquina de forma que diferentes clientes estén utilizando la aplicación al mismo tiempo; es decir en forma simultánea. Criterio de finalización: Éxito de prueba realizada al prototipo.

4.Pruebas de Carga:

Objetivos: Tiempo de respuesta del prototipo ante la interacción con el usuario. Cuya velocidad de respuesta, será analizada. Técnica: Se analizará el tiempo de respuesta. Criterio de finalización: Prueba de todas las peticiones de datos dentro de las diferentes cargas de trabajo del prototipo.

5.Pruebas de Seguridad: Objetivos: Seguridad optima ante casos de ataques cibernéticos.

Técnica: Se realizará diferentes ataques como proxy, wireshark. Criterios de finalización: La seguridad aceptable contra herramientas de cambio de estructura u cambio de contenido.

6.Prueba de Robustez: Objetivos: Validar si la entrada de datos es la correcta en el lugar

indicado. Técnica: Para ver la validación correcta se ingresará datos erróneos no correspondidos en su lugar. Criterios de finalización: Los datos ingresados son correctos las validaciones son las adecuadas.

7.Pruebas de desempeño: Objetivos: Soporte muchas entradas al software. 11

Técnica: Ingreso de distintos usuarios al sistema y no debe colgarse. Criterios de finalización: El sistema soporta y no llega a caer el sistema.

8.Pruebas de confiabilidad: Objetivos: Probar flujos antes de la producción y ejecución del sistema. Técnica: Probar los flujos mayormente los que son de Core de la bodega prueba de funcionalidad. Criterios de finalización: Los flujos son aceptables. 6.2.2

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 caso 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.

Caso De Prueba Aplicativo Requerimiento Proceso Caso de Uso Responsable Precondición

Sistema TuBodeguita Cus05-1 Registrar Producto Registrar Producto CUS05 Luis Lazo Haber iniciado sesión

12

Propósito

Este caso de uso permite al actor registrar la información de los productos al sistema

Escenarios

Agregar una nueva área de conocimiento Sec Actividad Clase de equivalencia . 1 Dirigir hacia la ruta: válida Mantenimiento de Producto 2 Seleccionar y clic en el botón válida nuevo 3 Ingresar los campos válida obligatorios. Nombre, precio y seleccionar una categoría. 4 Seleccionar y clic en el botón válida guardar 5 El sistema validara que se válida hayan ingresado los campos obligatorios

Resultado esperado Ingreso Nuevo Registro de campos Guardar Validar

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

Caso De Prueba Aplicativo Requerimiento Proceso Caso de Uso Responsable Precondición Propósito

Escenarios

Sistema TuBodeguita Cus06-1 Buscar Producto Buscar Producto CUS06 Luis Lazo Haber iniciado sesión Este caso de uso permite al actor filtrar la información de los productos al sistema

Agregar una nueva área de conocimiento Sec Actividad Clase de equivalencia . 1 Dirigir hacia la ruta: válida Mantenimiento de Producto 2 Seleccionar y clic en el botón válida filtrar

Resultado esperado Ingreso filtrado

Tabla Nº2 Formulario de Casos de Prueba con uso de Criterios de Especificación Formal, Clases de Equivalencia y Análisis de Valores Límite

Caso De Prueba Aplicativo Requerimiento Proceso Caso de Uso Responsable Precondición Propósito

Sistema TuBodeguita Cus07-1 Actualizar Producto Actualizar Producto CUS06 Luis Lazo Haber iniciado sesión Este caso de uso permite al actor actualizar la

13

información de los productos al sistema

Escenarios

Agregar una nueva área de conocimiento Sec Actividad Clase de equivalencia . 1 Selecciona de la grilla un válida producto para editar 2 Seleccionar y clic en el botón válida editar 3 Ingresar los campos válida obligatorios. Nombre, precio y seleccionar una categoría. 4 Seleccionar y clic en el botón válida guardar 5 El sistema validara que se válida hayan ingresado los campos obligatorios

Resultado esperado Selección Editar Registro de campos Guardar Validar

Tabla Nº3 Formulario de Casos de Prueba con uso de Criterios de Especificación Formal, Clases de Equivalencia y Análisis de Valores Límite

Caso De Prueba Aplicativo Requerimiento Proceso Caso de Uso Responsable Precondición Propósito

Escenarios

Sistema TuBodeguita Cus08-1 Eliminar Producto Eliminar Producto CUS06 Luis Lazo Haber iniciado sesión Este caso de uso permite al actor elimina la información de los productos al sistema

Agregar una nueva área de conocimiento Sec Actividad Clase de equivalencia . 1 Selecciona la grilla un válida producto 2 clic en el botón eliminar válida 3

El sistema validara que se seleccionó una categoría para eliminar

válida

Resultado esperado Selección Eliminar Validar

Tabla Nº4 Formulario de Casos de Prueba con uso de Criterios de Especificación Formal, Clases de Equivalencia y Análisis de Valores Límite

14

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

6.2.3



Que la encargada de Testing Luis Lazo (Tarea1), se ocupará de diseñar, generar, ejecutar y reportar los casos de prueba para los casos de uso de Módulo: (CUS05), Módulo para Registrar Producto, (CUS06), Módulo para Buscar Producto, (CUS07), Módulo para Actualizar producto, (CUS08), Módulo para Eliminar Producto.



Que la encargada de Testing Nahomi Castro (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

Ejecución de los Casos de Prueba Para la ejecución de los casos de prueba, teniendo el sistema TuBodeguita integrado, se aplicarán las entradas descritas para cada caso de prueba generado, a través de las interfaces del sistema, para ello se genera esta tabla, 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).

Código de Caso de Prueba CUS05 CUS06 CUS07 CUS08

Salida Esperada Registro de Producto Buscar Producto Actualizar Producto Eliminar Producto

Salida obtenida (*) Aceptada Aceptada Aceptada Aceptada

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: “Aceptable” (la salida obtenida está dentro del rango previsto por la salida esperada), “poco aceptable” (la diferencia entre las salidas es una cuestión de formato), “no aceptable” (el sistema no completó su salida o la completó, pero se "cayó" después). 6.2.4

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 15

 

6.2.5

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

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 “aceptable”) y fallas encontradas (resultado obtenido “poco aceptable o “no aceptable”). 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 aceptable, 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. 16

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: Luis Lazo, T2: Nahomi CASTRO SQA: David Montes, Líderes (Alejandro Castro, Fiorella Lazo, Alejandra Ramírez, Alfonso Pobes)  Comienzo: fecha en que comienza la actividad  Término: fecha en que termina la actividad  Duración: 30 días Actividad Casos de Prueba para Requerimientos Funcionales: modulo 1 Casos de Prueba para Requerimientos Funcionales: modulo 2 Informe de casos de pruebas de Sistema Revisión de Informe

Responsable

Comienzo

Término

Duración

T1

lunes 03-06-19

Sábado 08-06-19

6 días

T2

Sábado 08-06-19

Jueves 13-06-19

6 días

T1, T2

Viernes 14-06-19

Viernes 14-06-19

SQA(Asegura miento de la calidad del software), Líderes

Sábado 15-06-19

Lunes 17-06-19

Domingo 18-06-19 Lunes 19-06-19 Sábado 29-06-19

Domingo 18-06-19 Lunes 19-06-19 Domingo 30-06-19

1 día

T1, T2

Domingo 30-06-19

Domingo 30-06-19

1 día

SQA(Asegura miento de la calidad del software),, Líderes

Lunes 01-07-19

Lunes 01-07-19

Corrección de informe

T1, T2

Envío de pruebas a equipo

T1, T2

Ejecución de Casos de Prueba de Sistema Informe de Reportes de Pruebas de Sistema e Informe de análisis de resultados obtenidos Revisión de Reporte e informe de análisis

Líderes,T1, T2 BD (*)

Corrección de Reporte e Lunes Lunes T1, T2 informe de análisis 01-07-19 01-07-19 Envío de Informes de reporte y Martes Martes T1, T2 análisis a equipo 02-07-19 02-07-19 Tabla Nº3 de Actividades del plan de pruebas de sistema

1 día

3 días

1 día 2 días

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

17