Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Portafolio de Título
Caso N-4°
“Título del Caso Proyecto”
“No más accidentes”.
Fecha:[19/10/2019]
Resumen de riesgos 12
Caso N° 4.
Integrantes
Rut. Nombre. Correo.
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.
Gestionar clientes. Debería permitir registrar, editar, mostrar y elimina al cliente. Funcionales.
Gestionar planes y Gestar planes y costos tomando como referencia los módulos Funcionales.
costos. antes mencionados.
Ingresar fiscalización. Administrar solicitud que permita ser registrado siguiendo un Funcionales.
tipo y que esté enlazado a una actividad.
Estrategias de pruebas
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.
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.
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- 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.
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
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
Magnitud
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. 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”.
Definición de artefactos
Listar y describir los artefactos que serán administrados y entregados durante este proceso de prueba.
Artefacto Descripció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.
Desarrollo ineficiente. 5%