Plan de Pruebas Portafolio de Título Caso N-4° “Título del Caso Proyecto” Proyecto” “No más accidentes”. accidentes”. Fecha:[19/10/2019]
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Tabla de contenido Propósito del plan de pruebas.
4
Alcance de las pruebas
5
Definición de roles y responsabilidades
5
Tipos de pruebas a realizar r ealizar
6
Estrategia y técnicas de pruebas a aplicar
7
Definición del proceso de testing
7
Definición de ciclos de prueba a ejecutar
8
Calendarización Calendarizació n de las actividades de pruebas
10
Resumen de riesgos
12
Clasificación de los defectos
14
Condiciones de aceptación para cierre del proceso de pruebas
15
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Histórico de Revisiones Versión
Fecha
Descripción/cambio
autor
Versión 01.
15/10/2019.
Plan de pruebas.
Michal Orellana.
Versión 02.
19/10/2019.
Plan de pruebas.
Roberto Pizarro.
Información del Proyecto Organización
Duoc UC. Escuela de Informática y Telecomunicaciones
Sección
Sección cuatro.
Proyecto (Nombre)
“No más accidentes”. accidentes”.
Fecha de Inicio
12-8-2019.
Fecha de Término Caso N°
15-12-2019. 4.
Patrocinador principal
Empresa de asesoría prevención de riesgo.
Docente
Rodrigo Pinochet. Integrantes Rut.
Nombre.
Correo.
15.561.655-5
Christian Gomez.
[email protected]
18.817.532-5
Nicolás Tapia.
[email protected]
18.916.732-6
Ricardo Arredondo.
[email protected]
19.404.211-6
Michal Orellana.
[email protected]
18.654.740-3
Roberto Pizarro.
[email protected]
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Propósito del plan de pruebas. El propósito es establecer los posibles errores que pueda tener el sistema desarrollado, se utilizará una planificación inicial, casos de prueba e inspecciones, reportes de defectos e informe de cierre del proceso de prueba.
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Alcance de las pruebas Definición de requisitos de S.W., módulos de Software a probar, Requisitos ambiente de pruebas y Documentación Referenciada, etc. etc.
Módulos.
Funcionalidades.
Tipos de prueba.
Gestionar profesional.
Debería permitir el registrar, editar, mostrar y eliminar al profesional.
Funcionales.
Gestionar clientes.
Debería permitir registrar, editar, mostrar y elimina al cliente.
Funcionales.
Gestionar contratos.
Creación de contratos, editarlos, modificarlos y mostrarlos.
Funcionales.
Gestionar planes y costos.
Gestar planes y costos tomando como referencia los módulos antes mencionados.
Funcionales.
Gestionar actividades.
Registrar, editar, mostrar y eliminar actividades.
Funcionales.
Detalle actividad. Ingresar fiscalización.
Muestra en detalle de la actividad. Administrar solicitud que permita ser registrado siguiendo un tipo y que esté enlazado a una actividad.
Funcionales. Funcionales.
Acceso de actividad.
Registro de la actividad, listar, editar y eliminar.
Funcionales.
Reportar accidentes.
Está ligado al cliente y permite la administrado de los accidentes.
Funcionales.
Gestionar asistentes.
Creación, editar, mostrar y eliminar asistentes.
Funcionales.
Rubro.
Creación, editar, mostrar y eliminar asistentes.
Funcionales.
Definición de roles y responsabilidades Roles y responsabilidades de todos los participantes en el proceso de pruebas de SW. SW . Rol.
Responsabilidades
Relevancia
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Jefe de pruebas.
Michal Orellana.
Alta
Analista de calidad.
Roberto Pizarro.
Alta
Analista de sistema.
Ricardo Arredondo.
Alta.
Jefe del proyecto.
Nicolás Tapia.
Alta.
Ingeniero de sistemas.
Christian Gomez
Alta.
Tipos de pruebas a realizar Definir el tipo de pruebas que se debe desarrollar para este proyecto, actividades y responsables.
Tipo de prueba.
Actividades.
Responsables.
Funcionales.
Funciones o características que evalúan el software, ya que se valora el comportamiento externo del sistema (Lo que el sistema hace).
Roberto Pizarro.
No funcionales.
Se representan en “cómo funciona el sistema”. sistema”.
Michal Orellana.
Pruebas de arquitectura.
Se basan en la arquitectura del sistema mediante pruebas estructurales y técnicas estáticas.
Nicolas Tapia.
Pruebas de regresión.
Se aplican después que un defecto es identificado y corregido, ya que estas se repiten varias veces, se considera el utilizar una herramienta de automatización como lo es “Selenium”. “Selenium”.
Ricardo Arredondo.
Pruebas de
Se ejecutan como resultado de modificaciones, migraciones o
Christian Gomez.
mantenimiento.
desincorporación del software. Ejecutan correctivas, cambios en el entorno de sistema operativo, opera tivo, bases de datos, actualizaciones o parches, entre otros.
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Estrategia y técnicas de pruebas a aplicar Definir las estrategias y técnicas de pruebas que se debe desarrollar para este proyecto, actividades y responsables. Estrategias de pruebas Técnicas de prueba.
Actividades.
Responsables
Técnicas de caja blanca.
Minucioso examen de los detalles procedimentales del código a evaluar.
Roberto Pizarro.
Técnicas de caja negra.
Pruebas sobre la interfaz del programa a probar, se debe conocer las funcionalidades que se deben realizar.
Michal Orellana.
Técnicas de caja gris.
Combinación de técnicas de caja blanca y técnicas de caja Roberto Pizarro. negra.
Definición del proceso de testing Listar y describir todas las actividades a desarrollar en el proceso general de testing, responsables, artefactos, etc. etc.
Id.
Proceso general del testing.
Responsables.
Artefactos.
Sp-01.
Probar módulo de profesional.
Ricardo Arredondo.
Interfaz e ingreso de parámetros.
Sp-02.
Probar módulo de clientes.
Roberto Pizarro.
Interfaz e ingreso de parámetros.
Sp-03.
Probar módulo de Contratos.
Nicolás Tápia.
Interfaz e ingreso de parámetros.
Sp-04.
Probar módulo planes y costos.
Ricardo Arredondo.
Interfaz e ingreso de parámetros.
Sp-05.
Probar módulo de actividades.
Christian Gomez.
Generar check list, detalle de actividad y gestionar asistentes son necesarios para la realización de este módulo.
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Sp-06.
Probar módulo de fiscalización.
Christian Gomez.
Interfaz e ingresar como cliente al sistema.
Sp-07.
Probar módulo de detalle de actividades.
Christian Gomez.
Ingresar al sistema como profesional además de la interfaz de la misma
Sp-08.
Probar módulo de acceso a la
Christian Gomez.
Ingresar al sistema como cliente
actividad.
además de la interfaz de esta.
Sp-09.
Probar módulo de reportar accidentes.
Ricardo Arredondo
Ingresar al sistema como cliente además de la interfaz de esta.
Sp-10.
Probar módulo de ingresar asistente.
Roberto Pizarro.
Ingresar al sistema como cliente para que el módulo pueda ser visualizado.
SP-11.
Probar módulo de ingresar Rubro.
Michal Orellana.
Ingresar al sistema como cliente para que el módulo pueda ser probado.
SP-12.
Probar módulo de factura.
Ricardo Arredondo.
Ingresar al sistema mediante la interfaz, esta interfaz permite el descargar un documento pdf.
Definición de ciclos de prueba a ejecutar Listar y describir cantidad de ciclos de prueba a realizar en este proyecto, las tareas y actividades actividades para cada ciclo de prueba, responsables, artefactos, etc. etc.
Id.
Descripción.
Tareas y actividades.
Responsables.
SP01.
Requerimien tos de análisis.
En primer lugar se figuran los términos de los requerimientos que pueden ser probados, se debe interactuar con el cliente para que puedan ser entendidos en detalle.
Michal Orellana.
Artefactos.
Nicolás Tapia.
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
● Reglas de negocio definidas en un documento.. ● Arquitectura de diseño de los requerimientos. ● Integración de los requerimientos registrados.
SP02.
SP03.
Planificación de las pruebas.
Fase que define la estrategias que se realizarán de las pruebas, estimación de costos, los objetivos y los alcances de las pruebas.
Michal Orellana.
Casos de pruebas.
Se detallan los casos de prueba, además de preparar los datos para realizar las pruebas.
Michal Orellana.
Definir un software para probar las pruebas del equipo como también el poder ejecutar los casos de prueba.
Michal Orellana.
SP- Ambiente de 04. ejecución.
Roberto Pizarro.
Roberto Pizarro.
Roberto Pizarro.
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
● Análisis del productos. ● Diseño de la estrategias de las pruebas. ● Definir objetivos de las pruebas. ● Definición del criterio de las pruebas. ● Recursos a usar de la planificación. ● Ambiente a probar de las pruebas. ● Calendario y estimación de las pruebas. ● Determinar las pruebas que se entregarán. ● Documentar defectos encontrados. ● Definir casos de pruebas necesarios, simples y transparentes. ● Evitar casos de pruebas repetidos. ● Aseguramiento al 100% de los requerimientos que cubren al sistema. ● Implementación de las técnicas de pruebas. ● Que los casos de prueba generen el mismo resultado cada vez que estos se prueban. ● Probar las pruebas mediante un servidor. ● Es necesario tener conexión a internet
para analizar los requerimientos. ● Se deben ejecutar las pruebas en diversos navegadores. ● Se debe tener un reporte de los errores encontrados. ● Crear pruebas de datos para el ambiente de pruebas mediante una copia del software. SP05.
SP06.
Ejecución de las pruebas.
Pruebas finales y término del ciclo de pruebas.
Es un proceso el cual se ejecuta el código y se comparan las expectativas y los resultado obtenidos.
Michal Orellana. Roberto Pizarro.
Fase final del ciclo de vida de pruebas Michal Orellana. mediante una reunión con el equipo de Roberto Pizarro. las pruebas y evaluando el ciclo completo tomando como criterio las pruebas que cubren al software, calidad, costo, tiempo, objetivos esenciales del negocio y del software.
Calendarización de las actividades de pruebas
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
● Reporte de la ejecución de los casos de prueba. ● Reporte de defectos encontrados. ● Reporte del resumen de pruebas. ● Identificadores. ● Resumen de pruebas. ● Evaluaciones. ● Resumen de actividades. ● Aprobaciones
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Resumen de riesgos Listado de riesgos relacionado al proceso de pruebas de S.W. Indicar riesgo, magnitud o impacto de este riesgo por etapa en el proceso.Magnitud: Alto , Significativo Significa tivo , Moderado, Inferior y Baja. Baja. Evaluación de de riesgos
Fase del proceso de pruebas Planificació n
Análisis y diseño
Implement ación y ejecución
Evaluació n
Riesgo Cierre
Magnitud Alto.
Que la planeación y propuesta no sea definido correctamente. Que el cronograma presente errores al momento de no cumplir los plazos asignados.
Significativo . Alto.
Alta. Alta.
Falta de conocimiento conocimiento de una metodología al momento de ejecutar el proyecto. Los requerimientos son mal definidos.
Significativ o.
Alto.
Alto.
Baja.
Baja.
Significati vo.
Falta de disponibilidad de herramientas.
Alto.
Desarrolladores con muy atareados. Conflictos entre miembros del equipo , ya que, se reasignar las tareas debido a la ausencia de un miembro del equipo
Baja.
Falta de capacidad de autoestudio.
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Alta.
Falta capacidad para reflejar requerimientos en un prototipo.
Alta.
Instalacion de desarrollo no disponibles.
Significativ Alta.
Problemas en la instalación de
o. Alta.
software. Ambiente de trabajo para el diseño sin documentación.
Alto. Significativo .
Documentación no sigue el plazo asignado. Significativ o
Mala elección de herramientas. Moderado .
Alto.
Alto.
Alto.
Falta de conocimiento en las herramientas. Alto.
Alto.
Se hace un sistema como se cree cree que el usuario lo esperaría pero sin su aprobación.
Significativo .
Falta de disponibilidad de recursos de hardware. Baja.
Significativo .
Moderada.
Desarrollo ineficiente. Cambio de plataforma sobre la que se correrá el software.
Alta.
Estándares confusos en las interfaces. Inconsistencias al realizar la base de datos.
Significativa .
Significativ Alto. a. Significati vo.
Alto.
Subestimación del tamaño del software. El cliente no puede participar en revisiones y en reuniones. Persona clave no disponible en momentos críticos.
Alto.
Problemas al momento de contratar un servidor para la base de datos.
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Clasificación de los defectos Definir la clasificación de los defectos según su nivel de severidad s everidad Nivel de Severidad
Descripción
Alto.
Problemas de comunicación con el cliente cliente debido a que no está incluido en el proceso d del el software.
Alto.
Definición ambigua de los requerimientos del software.
Alto.
Avances sin autorización, lo cual el equipo de trabajo sin la ayuda del cliente debe definir los avances hasta la entrega final.
Alto.
Errores a la hora de diseñar el software debido debido a la inconsistencia del framework utilizado “Materialize”. “Materialize”.
Alto.
Errores sobre la documentación al momento momento de desarrollar el software.
Medio.
La aplicación no funciona si no se tiene conexión a internet.
Medio.
Incumplimiento de estándares de calidad al momento de probar los módulos.
Medio.
Errores de codificación al tratar de iniciar sesión en el software.
Definición de artefactos Listar y describir los artefactos que serán administrados y entregados durante este proceso de prueba. Artefacto
Descripción
Documentos pdf.
Mediante este documento se especifican los objetivos generales, específicos, requerimientos funcionales, requerimientos no funcionales, problemática y solución.
Imágenes.
Las imágenes sirven para organizar mediante “Puntos” a seguir para la confección de la documentación de las diversas partes del software.
Documento Word.
Se hace el borrador en un documento Word antes de convertirlo en .pdf para la entrega de iteración.
GitHub.
Permite al equipo de trabajo poder comunicarse para poder cohesionar el código que realiza cada uno sin generar inconsistencias.
Mail.
Permite que se tenga comunicación en el equipo de trabajo.
Planificación.
Carta Gantt que permite organizar al grupo de trabajo especificando plazos específicos para las diversas actividades que se debe realizar en el software. Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Nube (Drive)
Permite la comunicación y el traspaso de los diversos documentos que se necesitan para la documentación además de ser un medio efectivo para compartir información.
Condiciones de aceptación para cierre del proceso de pruebas Condiciones que se deben cumplir para dar término al proceso de pruebas y margen de tolerancia de aceptación de defectos.
Condiciones a cumplir.
Margen de tolerancia.
Que la planeación y propuesta no sea definido correctamente.
80%
Que el cronograma presente errores al momento de no cumplir los plazos asignados. asignados.
65%
Falta de conocimiento de una metodología al momento 80% de ejecutar el proyecto. Los requerimientos son mal definidos.
80%
Falta de disponibilidad de herramientas.
90%
Desarrolladores con muy atareados.
80%
Conflictos entre miembros del equipo , ya que, se reasignar las tareas debido a la ausencia de un
85%
miembro del equipo Falta de capacidad de autoestudio.
15%
Falta capacidad para reflejar requerimientos en un prototipo.
80%
Instalacion de desarrollo no disponibles.
80%
Problemas en la instalación de software.
85%
Ambiente de trabajo para el diseño sin documentación. documentación. 80%
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Documentación no sigue el plazo asignado.
80%
Mala elección de herramientas.
70%
Falta de conocimiento en las herramientas.
40%
Se hace un sistema como se cree que el usuario lo esperaría pero sin su aprobación.
100%
Falta de disponibilidad de recursos de hardware.
65%
Desarrollo ineficiente.
5%
Cambio de plataforma sobre la que se correrá el software.
45%
Estándares confusos en las interfaces.
80%
Inconsistencias al realizar la base de datos.
90%
Subestimación del tamaño del software. El cliente no puede participar en revisiones y en reuniones.
45%
Persona clave no disponible en momentos críticos.
80%
Problemas al momento de contratar un servidor para la base de datos.
80%
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
