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


Técnicas Pruebas para verificar la
de caja funcionalidad del sistema
negra
Técnicas Combinación de pruebas de
de caja caja blanca y negra, con el
gris objetivo de buscar defectos
debidos a una estructura
incorrecta o al uso incorrecto de
aplicaciones
Plan de Pruebas Portafolio de Título Ingeniería de Software – DuocUC
Plan de pruebas
Pruebas en la interfaz Christian
desarrollada en el sistema Cristi
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
Combinación de ambas José Garrido
técnicas utilizadas
Se aplicaran pruebas de matriz
y de regresión
 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