Plan de pruebas
Plan de Pruebas
Portafolio de Título
Caso N°5
“Control de Tareas”
Fecha:24/08/2021
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
Tabla de contenido
Propósito del plan de pruebas. 4
Alcance de las pruebas 4
Definición de roles y responsabilidades 7
Tipos de pruebas a realizar 8
Estrategia y técnicas de pruebas a aplicar 8
Definición del proceso de testing 10
Definición de ciclos de prueba a ejecutar 12
Calendarización de las actividades de pruebas 13
Resumen de riesgos 14
Clasificación de los defectos 15
Condiciones de aceptación para cierre del proceso de pruebas 16
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
Histórico de Revisiones
Versión Fecha Descripción/cambio autor
1.0 08/09/2021 Versión 1.0 Christian Cristi
1.1 08/09/2021 Revisión del documento José Garrido
Información del Proyecto
Organización Duoc UC. Escuela de Informática y Telecomunicaciones
Sección 002D
Proyecto (Nombre) Control de Tareas
Fecha de Inicio 24-08-2021
Fecha de Término 14-12-2021
Caso N° 5
Patrocinador principal Process SA
Docente Eliseo Concha P.
Integrantes
Rut Nombre Correo
19.986.535-8 Ricardo Sánchez ri.sanchezg@duocuc.cl
20.223.575-1 Michael Fuentes mic.fuentesb@duocuc.cl
20.198.140-9 José Garrido jo.garridoa@duocuc.cl
20.465.462-K Christian Cristi ch.cristi@duocuc.cl
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
Propósito del plan de pruebas
Propósito, objetivo, visión que se espera de este plan de pruebas.
El propósito de este plan de pruebas es detectar los posibles errores que pueda tener el software
desarrollado como solución al caso, con el fin de garantizar un funcionamiento pleno del sistema.
El Objetivo es establecer y coordinar una estrategia de trabajo para probar el desempeño
de producto desarrollado, encontrando errores y defectos con el fin de corregirlos. Se espera con
este documento tener una visión más clara de los procesos a realizar para el correcto desarrollo y
funcionamiento del sistema.
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
Roles del sistema El sistema de información debe considerar el rol de Funcional
administrador, diseñador de procesos y funcionario
Rol administrador El administrador podrá crear en el sistema todos los Funcional
recursos que el sistema necesita para su operación
(usuarios, roles, unidades y su jerarquía, etc.).
Creación de tareas Cada funcionario de acuerdo con su rol podrá crear tareas, Funcional
funcionario asignando un responsable y un plazo, adjuntando toda la
información necesaria para su desarrollo. Además, podrá
desagregar las tareas recibidas en tareas subordinadas bajo
el mismo concepto anterior. También podrá relacionar
tareas, pudiendo crear dependencias entre ellas.
Creación flujos de Cada diseñador de procesos podrá crear flujos de trabajo Funcional
trabajo diseñador “tipo”, los cuales podrán ser instanciados y asignados en
cualquier momento. Esto tiene sentido para procesos
repetitivos, los cuales se ejecutan en diferentes momentos
del año. El objetivo es generar el flujo de trabajo una vez, y
ejecutarlo varias veces, en diferente o mismo tiempo, con
diferentes o mismos responsables.
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
Recepción de tareas Cada funcionario podrá aceptar o rechazar la tarea Funcional
funcionario asignada, ingresando una justificación. Este acto tendrá
como consecuencia un aviso a quien asignó la tarea para
que resuelva el problema, replanteando la tarea, los plazos
o reasignando el responsable
Panel de control Cada funcionario tendrá acceso a un panel de control, el Funcional
funcionario cual muestra todas las tareas que tiene asignadas, su
porcentaje de cumplimiento de acuerdo al plazo. El
indicador debe ser mostrado como un semáforo, el cual
indique en verde las tareas en desarrollo que tengan un
plazo de entrega mayor a 1 semana, en amarillo las tareas
que estén con plazo de entrega menor a una semana y en
rojo las tareas atrasadas
Visualizar estado de Cada funcionario además podrá ver el estado de las tareas Funcional
tareas asignadas que se asigna y las subordinadas a ella.
funcionario
Cálculo de avance El cálculo de porcentaje de avance se hará considerando el Funcional
tareas tiempo transcurrido en relación con el plazo
Cálculo porcentaje El porcentaje global se calculará ponderando las tareas de Funcional
total acuerdo con su duración. Así mismo se calculará el avance
de una tarea de acuerdo a las tareas subordinadas
Marcar estado de Cada funcionario al ejecutar una tarea, o una tarea de un Funcional
tarea funcionario flujo podrá marcarla como terminada en cualquier
momento, quedando la tarea con un 100%
Reporte de Cada funcionario podrá reportar un problema en la Funcional
problema ejecución de la tarea, ingresando un mensaje, el cual será
funcionario alertado a quien asignó la tarea para su revisión, solución y
posibles cambios (asignación, plazo, etc.)
Visualizar carga de Cada funcionario de acuerdo con su rol podrá ver la carga Funcional
trabajo funcionario de trabajo de cada uno de los funcionarios subordinados
Acceso tablero El rol con mayor jerarquía tendrá acceso a un tablero global Funcional
global de control de control, el cual mostrará un resumen de tareas por
unidad interna, pudiendo mostrar el detalle de estas.
Además, incluirá los porcentajes de cumplimiento globales
y los detallados, para apoyar la toma de decisión
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
Módulos aplicación La aplicación debe estar compuesta por un módulo web y No
módulos de escritorio. Opcionalmente puede reemplazar el funcional
módulo de escritorio por aplicaciones móviles.
Construcción El módulo web debe ser construido mediante un modelo de No
módulos capas, logrando una separación de la interfaz gráfica, reglas funcional
de negocio y repositorio de datos
Procesos CRUD Los procesos CRUD se deben efectuar mediante No
procedimientos almacenados con PL/SQL. funcional
Utilización PL/SQL Considere utilizar PL/SQL para obtener las listas de datos No
mediante cursores. funcional
Notificaciones Las notificaciones a los clientes deberán realizarse No
clientes mediante correo electrónico, o bien, mediante funcional
notificaciones a dispositivos móviles
Formato La generación de reportes debe considerar el formato PDF No
generación de funcional
reportes
Medidas de El sistema debe incluir medidas de seguridad tales como No
seguridad enmascarar clave y control de sesiones. funcional
Elementos de Todas las aplicaciones de usuario deben presentar una No
diseño interfaz interfaz gráfica que considera los elementos de diseño funcional
gráfica incorporados en las aplicaciones de Windows
Autenticación de La autenticación de usuarios debe considerar las medidas No
usuarios de seguridad respectivas, tales como manejo de sesiones y funcional
acceso con usuario-clave-perfil a modo de acceder a las
funcionalidades de acuerdo al perfil o rol que posee el
usuario
Base de datos y El sistema debe utilizar base datos Oracle y lenguaje de No
lenguaje de programación orientado a objetos como Microsoft .NET y funcional
programación J2EE.
Manuales de El sistema debe contar con manuales de usuario No
usuario estructurados adecuadamente. funcional
Mensajes de error El sistema debe proporcionar mensajes de error que sean No
informativos y orientados a usuario final funcional
Validaciones Todas las entradas de datos deben considerar las No
entradas de datos validaciones correspondientes funcional
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
Aplicación web La aplicación web debe poseer un diseño “Responsive” a fin No
responsive de garantizar la adecuada visualización en múltiples funcional
computadores personales, dispositivos tablets y teléfonos
inteligentes
Alerta de atrasos El sistema será capaz de alertar mediante correo el No
incumplimiento o atraso en las tareas asignadas funcional
Error de En caso de no coincidir las credenciales de inicio de sesión No
credenciales se debe notificar que estas están erróneas funcional
Confirmación de Una vez concluyan las labores requerirán confirmación del No
tarea finalizada administrador para marcarlas como finalizadas funcional
Lenguaje fácil y La aplicación debe contener un lenguaje fácil y sencillo de No
sencillo comprender a nivel de usuario y al nivel de administrador funcional
Definición de roles y responsabilidades
Roles y responsabilidades de todos los participantes en el proceso de pruebas de SW.
Rol Responsabilidades Relevancia
Jefe de Proyecto Responsable del proyecto Alta
Líder de pruebas Responsable de la ejecución de las pruebas Alta
Analista QA Encargado del diseño de las pruebas Alta
Tester Encargado de ejecutar los casos de prueba Alta
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
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 Probar funcionalidades del sistema solicitadas por el Christian Cristi
cliente en la toma de requerimientos
No funcionales Probar el rendimiento del sistema construido Michael
Fuentes
Pruebas de Se realiza cuando se identifica un defecto y es José Garrido
regresión corregido, se pueden repetir muchas veces
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.
Técnicas Descripción Aplicación de prueba Responsables
de
prueba
Técnicas Pruebas centradas en los Se aplicarán pruebas de Michael
de caja detalles procedimentales del camino básico, los pasos a Fuentes
blanca software seguir para aplicar esta técnica
son:
1- Representar el
programa en un grafo
de flujo.
2- Calcular la complejidad
ciclomática.
3- Determinar el
conjunto básico de
caminos
independientes.
4- Derivar los casos de
prueba que fuerzan la
ejecución de cada
camino.
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
Técnicas Pruebas para verificar la Pruebas en la interfaz Christian
de caja funcionalidad del sistema desarrollada en el sistema Cristi
negra según cada caso de uso
especificado
Para cada prueba se debe:
- Verificar el resultado de la
interacción entre los actores y
el sistema
- Comprobar que se satisfagan
las precondiciones y
poscondiciones del caso de
uso.
- Comprobar que se siga la
secuencia de acciones
especificado por el caso de uso
Técnicas Combinación de pruebas de Combinación de ambas José Garrido
de caja caja blanca y negra, con el técnicas utilizadas
gris objetivo de buscar defectos Se aplicaran pruebas de matriz
debidos a una estructura y de regresión
incorrecta o al uso incorrecto de
aplicaciones
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
Definición del proceso de Testing
Listar y describir todas las actividades a desarrollar en el proceso general de testing, responsables,
artefactos, etc.
N° Proceso general de Responsables Artefactos
testing
PR°1 Probar roles del sistema Christian Cristi Permisos del sistema
PR°2 Probar rol administrador Christian Cristi Interfaz del sistema
PR°3 Probar creación de Michael Ingresar a interfaz del funcionario e
tareas funcionario Fuentes ingresar detalles de tareas, responsable
y plazos
PR°4 Probar creación flujos de José Garrido Ingresar a interfaz de diseñador e
trabajo diseñador ingresar flujos de trabajo
PR°5 Probar recepción de Michael Ingresar a interfaz de funcionario y
tareas funcionario Fuentes aceptar o rechazar tareas asignadas y
generar aviso a quien asignó esa tarea
PR°6 Probar panel de control Christian Cristi Interfaz del sistema
funcionario
PR°7 Probar visualizar estado Christian Cristi Ingresar a interfaz funcionario y
de tareas asignadas visualizar estado de las tareas asignadas
funcionario
PR°8 Probar cálculo de avance José Garrido Ingresar al sistema y visualizar el cálculo
tareas de porcentaje de avance de tareas en
relación con el plazo
PR°9 Probar cálculo José Garrido Ingresar al sistema y visualizar el cálculo
porcentaje total total de avance del proyecto
PR°10 Probar marcar estado de Christian Cristi Ingresar a la interfaz funcionario y
tarea funcionario gestionar estado de tarea
PR°11 Probar reporte de Michael Ingresar a interfaz de funcionario e
problema funcionario Fuentes ingresar reportes de problemas con
tareas
PR° 12 Probar visualizar carga de Michael Ingresar al sistema y visualizar carga de
trabajo funcionario Fuentes trabajo
PR°13 Probar acceso tablero José Garrido Ingresar al sistema y realizar tareas de
global de control gestión de usuarios
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
PR°14 Revisar módulos Ricardo Comprobar que el sistema funcione en
aplicación Sánchez los módulos requeridos por el cliente
PR°15 Revisar construcción Ricardo Comprobar construcción de módulos
módulos Sánchez
PR°16 Revisar procesos CRUD Ricardo Comprobar si existen procedimientos
Sánchez almacenados
PR°17 Revisar utilización PL/SQL Michael Utilización de PL/SQL para obtener las
Fuentes listas de datos mediante cursores.
PR°18 Probar notificaciones José Garrido Comprobar si las notificaciones a los
clientes clientes llegan de la forma solicitada
PR°19 Comprobar formato Christian Cristi Generación de reportes
generación de reportes
PR°20 Probar medidas de José Garrido Medidas de seguridad eficientes
seguridad
PR°21 Comprobar elementos de Ricardo Interfaz del sistema
diseño interfaz gráfica Sánchez
PR°22 Probar autenticación de Christian Cristi Autenticación de usuario según
usuarios credenciales
PR°23 Revisar base de datos y Michael Lenguaje de programación y base de
lenguaje de Fuentes datos utilizada
programación
PR°24 Revisar manuales de Ricardo Manuales de usuario del sistema
usuario Sánchez
PR°25 Probar mensajes de error José Garrido Provocar error en el sistema
PR°26 Probar validaciones Christian Cristi Ingresar datos
entradas de datos
PR°27 Comprobar aplicación Ricardo Aplicación web
web responsive Sánchez
PR°28 Comprobar alerta de Michael Alerta de atrasos del proyecto
atrasos Fuentes
PR°29 Comprobar error de Michael Ingreso al sistema
credenciales Fuentes
PR°30 Probar confirmación de Christian Cristi Informar sobre la finalización de la tarea
tarea finalizada programada
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
PR°31 Comprobar lenguaje fácil José Garrido Interfaz del sistema
y sencillo
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.
N° Descripción Tareas y actividades Responsables Artefactos
PR°1 Requerimientos El primer ciclo de Ricardo ● Reglas de negocio
de análisis pruebas, se figuran Sánchez definidas
los términos de ● Arquitectura de
requerimientos que Michael diseño de
pueden ser probados, Fuentes requerimientos
en conjunto al cliente ● Integración de los
para entender en requerimientos
detalle registrados
PR°2 Planificación de Se definen las Christian ● Análisis del
las pruebas estrategias con las Christi negocio
que se realizarán las ● Calendario y
pruebas, estimación José Garrido estimación de las
de costos, objetivos y pruebas
alcances de pruebas ● Diseño de
estrategia de
pruebas
● Tipos de prueba
PR°3 Casos de prueba Se establecen los Michael ● Documentación
casos de prueba, el Fuentes de defectos
cual determina ● Definir casos de
resultados parciales o José Garrido prueba
satisfactorias ● Implementación
de técnicas de
prueba
PR°4 Ambiente de Definir un ambiente Ricardo ● Prueba de
ejecución o software para Sánchez aplicaciones
probar los cambios desde un servidor
dentro la codificación Michael local
de los sistemas Fuentes ● Pruebas en
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
distintos
navegadores web
PR°5 Ejecución de las Ejecutar las pruebas Christian ● Reporte de
pruebas para comparar las Christi defectos
expectativas y la ● Pruebas de
resolución para la José Garrido desempeño
espera de resultados ● Pruebas de
positivos ejecución
PR°6 Pruebas de Fase final del ciclo de Ricardo ● Reporte del
aceptación y pruebas mediante Sánchez resumen de
cierre del ciclo de una reunión con el pruebas
pruebas equipo de las Michael ● Resumen de
pruebas y evaluando Fuentes pruebas
el ciclo completo ● Evaluaciones
tomando como ● Resumen de
criterio las pruebas ● actividades
que cubren al ● Aprobaciones
software, calidad,
costo, tiempo,
objetivos esenciales
del negocio y del
software.
Calendarización de las actividades de pruebas
Listado de actividades, tareas, duración, fechas, responsables, etc.
Referenciada en Carta Gantt
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
Resumen de riesgos
Listado de riesgos relacionados 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.
Fase del proceso de pruebas Riesgo
Planificación Análisis y Implementación Evaluación Cierre
diseño y ejecución
M
a
Alto SIN SIN IMPACTO SIN SIN Planeación y propuesta
g
IMPACTO IMPACTO IMPACTO definida de forma
n incorrecta
i
t Significati SIN SIN IMPACTO SIN SIN Cronograma con errores
u vo IMPACTO IMPACTO IMPACTO al no cumplir con los
d plazos asignados
SIN SIN Alto SIN SIN Requerimientos mal
IMPACTO IMPACTO IMPACTO IMPACTO definidos
SIN SIN Significativo SIN SIN Falta de herramientas
IMPACTO IMPACTO IMPACTO IMPACTO para testing
SIN SIN Alto SIN SIN Desarrolladores con
IMPACTO IMPACTO IMPACTO IMPACTO mucho trabajo
Alto SIN SIN IMPACTO SIN SIN Conflictos entre
IMPACTO IMPACTO IMPACTO miembros del equipo , ya
que, se reasignar las
tareas debido a la
ausencia de un miembro
del equipo
SIN SIN Alto SIN SIN Instalaciones de
IMPACTO IMPACTO IMPACTO IMPACTO desarrollo no disponibles.
Alto SIN SIN IMPACTO SIN SIN Documentación no sigue
IMPACTO IMPACTO IMPACTO el plazo asignado
SIN Significati SIN IMPACTO SIN SIN Mala elección de
IMPACTO vo IMPACTO IMPACTO herramientas
SIN SIN Significativo SIN SIN Falta de conocimiento en
IMPACTO IMPACTO IMPACTO IMPACTO las herramientas.
Significati SIN SIN IMPACTO SIN SIN Falta de disponibilidad de
vo IMPACTO IMPACTO IMPACTO recursos de hardware
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
SIN SIN Moderado SIN SIN Desarrollo ineficiente.
IMPACTO IMPACTO IMPACTO IMPACTO
SIN SIN Alto SIN SIN Inconsistencias al realizar
IMPACTO IMPACTO IMPACTO IMPACTO la base de datos.
Clasificación de los defectos
Definir la clasificación de los defectos según su nivel de severidad
Nivel de Descripción
Severidad
Alto Mal entendimiento de los requisitos entregados por el cliente
Alto Cambio en los requerimientos
Alto Mala calendarización
Alto Errores sobre la documentación al momento de desarrollar el software
Alto Insatisfacción por parte del Cliente.
Medio Incumplimiento de estándares de calidad al momento de probar los
módulos
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
Definición de artefactos
Listar y describir los artefactos que serán administrados y entregados durante este proceso de prueba.
Artefacto Descripción
Documento PDF Documento final en el cual se especifican los objetivos generales,
específicos, requerimientos funcionales, requerimientos no
funcionales, problemática y solución.
Documento Word Documento editable
Planificación Carta Gantt planificando los tiempos
Drive Permite el traspaso de forma cómoda de documentos
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.
Se espera contar con un resultado de éxito del 98% para la validación del proyecto. No obstante,
si no se cumple con el 98% se considerará el 95% de resultados positivos, siempre y cuando no se
vea invalidado ningún módulo del sistema.
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
