Está en la página 1de 16

Plan de Pruebas

Portafolio de Título
Caso N-4°
“Título del Caso Proyecto”
“No más 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 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 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”.

Fecha de Inicio 12-8-2019.

Fecha de Término 15-12-2019.

Caso N° 4.

Patrocinador principal Empresa de asesoría prevención de riesgo.

Docente Rodrigo Pinochet.

Integrantes
Rut. Nombre. Correo.

15.561.655-5 Christian Gomez. ch.gomez@alumnos.duoc.cl

18.817.532-5 Nicolás Tapia. ni.tapiam@alumnos.duoc.cl

18.916.732-6 Ricardo Arredondo. ric.arrerondo@alumnos.duoc.cl

19.404.211-6 Michal Orellana. mich.orellana@alumnos.duoc.cl

18.654.740-3 Roberto Pizarro. rob.pizarroc@alumnos.duoc.cl

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.

Módulos. Funcionalidades. Tipos de prueba.

Gestionar profesional. Debería permitir el registrar, editar, mostrar y eliminar al Funcionales.


profesional.

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 Gestar planes y costos tomando como referencia los módulos Funcionales.
costos. antes mencionados.

Gestionar actividades. Registrar, editar, mostrar y eliminar actividades. Funcionales.

Detalle actividad. Muestra en detalle de la actividad. Funcionales.

Ingresar fiscalización. Administrar solicitud que permita ser registrado siguiendo un Funcionales.
tipo y que esté enlazado a una actividad.

Acceso de actividad. Registro de la actividad, listar, editar y eliminar. Funcionales.

Reportar accidentes. Está ligado al cliente y permite la administrado de los Funcionales.


accidentes.

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.

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 Roberto Pizarro.


valora el comportamiento externo del sistema (Lo que el sistema
hace).

No funcionales. Se representan en “cómo funciona el sistema”. Michal Orellana.

Pruebas de Se basan en la arquitectura del sistema mediante pruebas Nicolas Tapia.


arquitectura. estructurales y técnicas estáticas.

Pruebas de Se aplican después que un defecto es identificado y corregido, Ricardo Arredondo.


regresión. ya que estas se repiten varias veces, se considera el utilizar una
herramienta de automatización como lo es “Selenium”.

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, 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 Roberto Pizarro.
código a evaluar.

Técnicas de caja negra. Pruebas sobre la interfaz del programa a probar, se debe Michal Orellana.
conocer las funcionalidades que se deben realizar.

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.

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 Christian Gomez. Ingresar al sistema como profesional
actividades. 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 Ricardo Arredondo Ingresar al sistema como cliente
accidentes. además de la interfaz de esta.

Sp-10. Probar módulo de ingresar Roberto Pizarro. Ingresar al sistema como cliente
asistente. 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 para cada ciclo
de prueba, responsables, artefactos, etc.

Id. Descripción. Tareas y actividades. Responsables. Artefactos.

SP- Requerimien En primer lugar se figuran los términos Michal Orellana. ● Reglas de negocio
01. tos de de los requerimientos que pueden ser definidas en un
análisis. probados, se debe interactuar con el Nicolás Tapia. documento..
cliente para que puedan ser ● Arquitectura de
entendidos en detalle. diseño de los
requerimientos.
● Integración de los
requerimientos
registrados.

Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC


SP- Planificación Fase que define la estrategias que se Michal Orellana. ● Análisis del
02. de las realizarán de las pruebas, estimación productos.
pruebas. de costos, los objetivos y los alcances Roberto Pizarro. ● Diseño de la
de las pruebas. 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.

SP- Casos de Se detallan los casos de prueba, Michal Orellana. ● Documentar


03. pruebas. además de preparar los datos para defectos
realizar las pruebas. Roberto Pizarro. 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.

SP- Ambiente de Definir un software para probar las Michal Orellana. ● Probar las pruebas
04. ejecución. pruebas del equipo como también el mediante un
poder ejecutar los casos de prueba. Roberto Pizarro. servidor.
● Es necesario tener
conexión a internet

Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC


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.

SP- Ejecución de Es un proceso el cual se ejecuta el Michal Orellana. ● Reporte de la


05. las pruebas. código y se comparan las expectativas ejecución de los
y los resultado obtenidos. Roberto Pizarro. casos de prueba.
● Reporte de
defectos
encontrados.

SP- Pruebas Fase final del ciclo de vida de pruebas Michal Orellana. ● Reporte del
06. finales y mediante una reunión con el equipo de resumen de
término del las pruebas y evaluando el ciclo Roberto Pizarro. pruebas.
ciclo de completo tomando como criterio las ● Identificadores.
pruebas. pruebas que cubren al software, ● Resumen de
calidad, costo, tiempo, objetivos pruebas.
esenciales del negocio y del software. ● Evaluaciones.
● Resumen de
actividades.
● Aprobaciones

Calendarización de las actividades de pruebas

Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC


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 , Moderado, Inferior y Baja.

Evaluación Fase del proceso de pruebas Riesgo


de de riesgos
Planificació Análisis y Implement Evaluació Cierre
n diseño ación y n
ejecución

Magnitud

Alto. Que la planeación y propuesta no


sea definido correctamente.

Significativo Que el cronograma presente


. errores al momento de no cumplir
los plazos asignados.

Alto. Falta de conocimiento de una


metodología al momento de
ejecutar el proyecto.

Alta. Los requerimientos son mal


definidos.

Alta. Significativ Significati Falta de disponibilidad de


o. vo. herramientas.

Alto. Desarrolladores con muy


atareados.

Alto. Alto. Conflictos entre miembros del


equipo , ya que, se reasignar las
tareas debido a la ausencia de un
miembro del equipo

Baja. Baja. 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. software.

Alta. Ambiente de trabajo para el


diseño sin documentación.

Alto. Documentación no sigue el plazo


asignado.

Significativo Significativ Mala elección de herramientas.


. o

Moderado Falta de conocimiento en las


. herramientas.

Alto. Alto. Alto. Alto. Alto. Se hace un sistema como se cree


que el usuario lo esperaría pero
sin su aprobación.

Significativo Falta de disponibilidad de


. recursos de hardware.

Baja. Desarrollo ineficiente.

Significativo Moderada. 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. Subestimación del tamaño del


. a. software.

Significati El cliente no puede participar en


vo. revisiones y en reuniones.

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

Nivel de Descripción
Severidad

Alto. Problemas de comunicación con el cliente debido a que no está incluido en el proceso del
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 a la inconsistencia del framework utilizado
“Materialize”.

Alto. Errores sobre la documentación al 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 80%


correctamente.

Que el cronograma presente errores al momento de 65%


no cumplir los plazos asignados.

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 85%


reasignar las tareas debido a la ausencia de un
miembro del equipo

Falta de capacidad de autoestudio. 15%

Falta capacidad para reflejar requerimientos en un 80%


prototipo.

Instalacion de desarrollo no disponibles. 80%

Problemas en la instalación de software. 85%

Ambiente de trabajo para el diseño sin 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 100%


esperaría pero sin su aprobación.

Falta de disponibilidad de recursos de hardware. 65%

Desarrollo ineficiente. 5%

Cambio de plataforma sobre la que se correrá el 45%


software.

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 45%


reuniones.

Persona clave no disponible en momentos críticos. 80%

Problemas al momento de contratar un servidor para 80%


la base de datos.

Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC

También podría gustarte