1

FASE 5 DESARROLLO

AP09-AA10-EV02. DISEÑO Y EJECUCIÓN DE PLAN DE PRUEBAS DEL SISTEMA DE

INFORMACIÓN.

Kevin Montoya Arias

Aprendiz

Karen Vanessa Lozano Manrique

Instructor

Tecnólogo en Análisis y Desarrollo de Sistemas de Información

SERVICIO NACIONAL DE APRENDIZAJE

SENA Palmira - COLOMBIA
2023
 2

VERSION FECHA PUNTO CAMBIOS PREPARADO APROBADO

RESPECTO A POR POR
LA VERSION
ANTERIOR
RESOS
9/12/2022 Versión Inicial Kevin Karen
1.0
Montoya Vanessa
Arias Lozano
Manrique
 3

Tabla de Contenidos

Introducción…...............................................................................................................................4
Alcance de las pruebas del sistema de información…...................................................................4
Definiciones y Acrónimos............................................................................................................4,5
Referencias...................................................................................................................................5,6
Visión general del documento…....................................................................................................7
Descripción del ambiente de pruebas (Precondiciones yPostcondiciones)..................................8,9
Casos de pruebas unitarias.............................................................................................................10
Casos de pruebas integrales...........................................................................................................11
Ajustes y recomendaciones............................................................................................................12
Anexos............................................................................................................................................13
Casos de pruebas (Plantilla de casos deprueba).............................................................................13
Conclusión…..................................................................................................................................14
 4

Introducción

En el ejercicio de la gestión de la calidad, las pruebas que se realizan al software son el

mecanismo por el cual el proceso de verificación y validación tiene éxito. Este proceso, es

Gestión de la Calidad
Plan de
Sistema de Aseguramiento de Verificación Y
Control de
Gestión de la la Calidad (PAQ) Validación
Calidad
calidad

Alcance de las pruebas del sistema de información

El proceso de verificación y validación del software del proceso de aseguramiento de la calidad,

se tomen en cuenta:
 Requerimientos funcionales y requerimientos no funcionales del software.
 Fallos e inconsistencias del sistema.
 Pruebas estáticas y pruebas dinámicas del sistema.

Definiciones

Prueba: Una actividad en la cual un sistema o componente es ejecutado bajo condiciones

específicas, se observan o almacenan los resultados y se realiza una evaluación de algún
aspecto del sistema o componente.
Casos de Prueba: Un conjunto de entradas, condiciones de ejecución y resultados esperados,
diseñados para un objetivo particular.
Equivocación: Una acción del ser humano que produce un resultado incorrecto.
 5

Error: La diferencia entre un valor calculado, observado o medido y el valor verdadero,

especificado o teóricamente correcto.
Fallo: La incapacidad de un sistema o de alguno de sus componentes para realizar las
funciones requeridas dentro de los requisitos de rendimiento especificados.
Defecto: Un paso, proceso o definición de dato incorrecto en un programa de computadora. EL
resultado de una equivocación.
Depuración: El proceso de localizar, analizar y corregir los defectos que se sospecha que
contiene el software.
Verificación: Un conjunto de actividades que aseguran que el software implementa
correctamente una función específica. (¿Estamos construyendo el producto correctamente?).
Validación: Un conjunto diferente de actividades que aseguran que el software construido se
ajusta a los requisitos del cliente. (¿Estamos construyendo el producto correcto?).
Testware: Es el producto resultante de las pruebas.

Acrónimos

 SQA: Software Quality Assurance (Aseguramiento de Calidad de Software)

 GUI: Graphical User Interface (Interfaz Gráfica)
 PDL: Program Desing Language (Lenguaje de Diseño de Programas)
 UD: Use-Definition Chain (Cadena Definición-Uso)
 OO: Object-Oriented (Orientado a Objetos)

Referencias

Proyecto Tipo de Proyecto

Resos 1.0 Proyecto de desarrollo Aplicación Móvil para
Android.

Documentos Evaluación Relacionados

Casos de pruebas (Plantilla de casos de prueba)
Equipo de Proyecto
Equipo de Trabajo Kevin Montoya Arquitecto de Kevin Montoya
Arias Arias
 6

Lozano Producto Lozano

Visión General Del Documento

1.1. Objetivos Del Plan De Pruebas

Este documento, tiene como finalidad entregar las pautas y definir la estrategia que se seguirá
para llevar a cabo la certificación del software Resos 1.0 – Aplicación Móvil para la empresa
Postobón s.a.

El objetivo general del plan es establecer la cronología y condiciones para la aplicación de las
pruebas de manera que pueda resultar un sistema que sea completado y tenga gran acogida de los
interesados de este modo entrar en operación con todas las funcionalidades requeridas para su
puesta en marcha.

1.2. Documentos Relacionados

Nombre Descripción
Informe de requisitos Versión 1.0 Informe de requisitos
Informe de análisis y diseño Versión 1.1 Informe de análisis y diseño

Descripción del Ambiente de Pruebas (Precondiciones y Postcondiciones)

2. Alcance de las Pruebas

Mediante los siguientes cuadros se describen los requerimientos de pruebas del sistema NSGT,
incluidos y excluidos en la presente certificación del sistema Resos 1.0.

2.1. Cuadro Resumen De Las Pruebas

Modulo del sistema a ser aprobados Módulos:

-Proyectos
 7

- Revisión
- Aprobación
Objetivos de las Pruebas En estos módulos se realizarán pruebas
para validar:

- La visualización de los datos, Ingresados o

modificados
- La operación de los servicios,
diseñados para dar respuesta a los
productos del sistema Resos 1.0.
- La respuesta y realización de las
transacciones de cada módulo.
- Que los estados de las actividades y
documentos generados en el sistema se
reflejen de acuerdo a la secuencia
lógica requerida por el usuario.
- La secuencia lógica de las funcionalidades
y transacciones.
Detalle del orden de ejecución de los Los módulos se deben ejecutar en
forma módulos independiente, pero consecutivos en el
orden siguiente:
- Proyectos
- Revisión
- Aprobación
Responsabilidad de la Prueba Las pruebas son responsabilidad del
Testing Operacional del equipo de
proyecto, quien en conjunto con el usuario
deben seleccionar las pruebas que se
aseguren de la efectividad del sistema.

2.2 Requerimientos De Pruebas Excluidos

Nombre Descripción Tipo Nivel Criticidad (Bajo-Medio-Alto)

 8

N/A N/A N/A N/A

2.3. Casos De Pruebas Incluidos

# Casos # Estimado de Tipo Modulo Total Casos

Disponibles Casos Nuevos
150 30 Funcional Proyectos
50 11 Funcional Revisión
45 8 Funcional Aprobación
245

2.4. Casos De Pruebas Excluidos

# Casos Disponibles # Estimado Casos Tipo Modulo

Nuevos
N/A N/A N/A N/A

3. Entorno Y Configuración De Las Pruebas

Para el proceso de pruebas del proyecto se requiere de la disponibilidad de los siguientes

entornos, a saber:
a. Computador con Windows 10 con acceso a internet.
b. Equipo Cliente: Equipo de prueba
- PC1 ASUS TP412U Intel Core I3 – 4 Gb Ram – SSD 256 Gb
c. Base de datos MYSQL, Google Crome, Spring Tool Suite 4, Postman, Android Studio.
Estos softwares se encontrarán instalados en el equipo, ya que se va a trabaja como un
servidor local para realizar las pruebas detallado en el punto (a) del entorno y
configuración de las pruebas.

Todos ellos instalados y configurados por el equipo de trabajo de la empresa CreApp s.a.s,
diseñadores del sistema Resos 1.0.
 9

3.1. Criterios De Inicio

Aceptación del plan de pruebas. Revisión y aceptación del documento que contiene los casos de
pruebas para la certificación del proyecto.

Aceptación de paquetes. Revisión y aceptación de los paquetes de desarrollo y que este cumpla
con las condiciones de aceptación.

Aceptación de ambiente. Revisión y aceptación del ambiente de certificación y que este cumpla
con las condiciones de aceptación.

3.2. Bases De Datos De Pruebas

Administradores de base de datos de, MYSQL

MYSQL es un sistema de gestión de bases de datos relacionales multiplataforma, multiproceso y
multiusuario, distribuido bajo un sistema de licencia gratuita.

Lenguaje de programación, JAVA

Lenguaje orientado a objetos, su intención es permitir que los desarrolladores de aplicaciones escriban el
programa una sola vez y lo ejecuten en cualquier dispositivo, es robusto, seguro y portable.

Eclipse
Plataforma de software compuesto por un conjunto de herramientas de programación de código abierto
multiplataforma para desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido", opuesto
a las aplicaciones "Cliente-liviano" basadas en navegadores., usada para desarrollar en entornos de
desarrollo integrados como el IDE de JAVA.

Entorno de desarrollo Android Studio

Android Studio es el entorno de desarrollo integrado (IDE) oficial para el desarrollo de apps
para Android, basado en IntelliJ IDEA, Un entorno unificado donde puedes desarrollar para todos los
dispositivos Android.
 10

Spring Source Tool Suite

(STS) es un IDE basado en la versión Java EE de Eclipse, pero altamente customizado para trabajar
con Spring Framework. Entre las características más destacadas que STS proporciona se encuentran:
Soporte para Spring 3. Asistentes para la creación de proyectos Spring, permite el desarrollo de Api con
Spring Boot.

Postman
Herramienta que principalmente nos permite crear peticiones sobre APIs de una forma muy sencilla y
poder, de esta manera, probar las APIs......Alrededor de la idea de testear las APIs, Postman nos ofrece un
conjunto de utilidades adicionales para poder gestionar las APIs de una forma más sencilla.

3.3. Criterios de Aprobación/Rechazo

Errores Graves: información crítica presentada erróneamente, información mal registrada en la

base de datos, caídas de programas, incumplimiento de objetivos en funciones principales, etc.

Errores Medios (comunes): errores en documentos impresos que se entregan a personas ajenas
a la organización, errores en presentación de datos, incumplimiento de objetivos en funciones
secundarias, caídas de programas auxiliares, etc.
Errores Leves: errores en presentación de datos secundarios, no adecuación a estándares,
comportamientos correctos pero diferentes en situaciones similares, dificultades de operación,
etc.

Nombre Descripción
1 Se aprobará el proyecto con un 100% de las
pruebas ejecutadas, pero con una 90% de
aceptación. Esto quiere decir el 90% de las
pruebas deben ser exitosas y sin errores. El
restante 10% pueden existir errores medios o
bajos, pero NO graves.
 11

En caso de ocurrir que el proyecto no cumpla

con el nivel exigido, el proyecto se rechaza
completo en su etapa de certificación.

4. Estrategias De Pruebas

Se requiere certificar por parte del equipo de desarrollo y por parte del cliente al producto
Resos 1.0 – Aplicación Móvil que se encargará atender solicitudes o requerimientos de clientes
por la compañía Postobón s.a.

1ra. Etapa: Que las funcionalidades de los módulos de proyectos y de revisión sean operativas.
2da. Etapa: Que las funcionalidades integradas de los módulos de proyectos, revisión y
aprobación sean operativas.
Conjuntamente los sub-objetos para los tres módulos se resumen de la siguiente forma:

o El ingreso y la postulación de las propuestas técnicas y sus empleados asociados.

o La creación, modificación y eliminación de acuerdo a los permisos.
o La revisión y aprobación de los entregables de cada proyecto.
o La visualización, modificación y eliminación del calendario de evaluaciones y reuniones.
o Que los documentos y actividades se generen con su estado correspondiente en el
sistema.

4.1. Escenario De Las Pruebas

Para cumplir con los objetivos planteados deben existir tres escenarios, que son:

Pruebas de Instalación: Se debe comprobar que:

- Las aplicaciones no presentan anomalías.
- Que apunta al servidor y base de datos definidos.
 12

Pruebas de GUI o Interfaz: Se debe comprobar que:

- El comportamiento del sistema de información con casos de los bordes inválidos y
válidos, donde las pruebas de borde se definen como aquellas pruebas en las cuales los
datos de prueba a utilizar son valores límites.
- Carga, despliegue, foco, modalidad, navegabilidad y usabilidad de las GUI del sistema y
sus elementos. Donde las métricas y heurísticas de usabilidad y funcionalidad a utilizar
sean las siguientes:
o Comprensión global del sitio.
o Aspectos de interfaces y estéticos.
o Métricas de confiabilidad.
o Navegación y exploración.

Pruebas de operación y funcionales: Se debe comprobar que:

- El comportamiento del sistema de información con casos inválidos y válidos, de flujo

completo del proceso de las propuestas y proyectos.
- El comportamiento del sistema de información con casos inválidos y válidos, de flujo
completo del proceso de los artículos ingresados en productos.
- El comportamiento del sistema de información con casos inválidos y válidos, de flujo
completo del proceso de las diferentes actividades relacionadas a una propuesta y
proyecto de gestión de atención al cliente de la empresa Postobón s.a.
- El comportamiento del sistema de información para el módulo de contrato.
- El comportamiento del sistema de información para el módulo de clientes, activos,
desperfectos, toma fotográfica, empleados y usuarios.
- El comportamiento del sistema de información para el módulo de solicitudes y detalle de
solicitud.

4.2 Orden De Ejecución De Pruebas

 13

Las pruebas se llevarán a cabo de la siguiente forma:

Secuencias de pasos para la configuración.

1. Configuración del equipo del cliente del servidor y de la base de datos.

Secuencias de pasos para la generación de archivos para los módulos.

1. Ejecución de proceso (Manual) de generación de archivos de entrada y salida con la
información de los activos y atención para alimentar al sistema de información Resos 1.0.

Secuencias de pasos para la generación de datos para los módulos.

1. Ejecución del proceso (manual) de generación de datos, donde las tablas y campos a utilizar
serán llenados manualmente.

4.3. Equipo De Pruebas Y Responsabilidades

Nombre Responsabilidad
Kevin Montoya Arias Arquitectos de producto, responsable de
evaluar las condiciones de término para el
proceso de pruebas junto al Jefe de Proyectos.
Kevin Montoya Arias Jefes de Proyectos, responsable de evaluar las
condiciones de término para el proceso de
pruebas junto al Arquitecto de Producto.
Kevin Montoya Arias Analista funcional, responsable de la
resolución de las incidencias de certificación
para los módulos de Proyectos, Revisión y
Aprobación.
Kevin Montoya Arias Testing de Solución, responsable de la
generación del plan de pruebas.
 14

Conclusión

En el instante que comprendamos la importancia de un buen diseño, una buena planeación, y ejecución
de pruebas vamos a agradecer la implementación de todo el proceso de desarrollo de nuestro sistema de
información, empezando desde la recolección de datos con los diferentes medios, pasando por los diseños
creados en StarUML hasta implementar el desarrollo del sistema de información con la tecnología
seleccionada.