FECHA PUNTO CAMBIOS PREPARADO APROBADO

RESPECTO A POR POR

LA VERSION
ANTERIOR

Version Inicial
 INTRODUCCIÓN
En el ejercicio de la administración de la calidad, las pruebas que se hacen al programa
son el mecanismo por el que el proceso de verificación y validación tiene triunfo. Este
proceso, es

Alcance de las pruebas del sistema de información

El proceso de verificación y validación del programa del proceso de aseguramiento
de la calidad, se consideren:
 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 elemento es ejecutado bajo condiciones

específicas, se observan o almacenan los resultados y se hace una evaluación de algún
aspecto del sistema o elemento.

Casos de Prueba: Un grupo de entradas, condiciones de ejecución y resultados

esperados, diseñados para un objetivo especial.

Equivocación: Una acción de las personas que crea un resultado erróneo.

Error: La diferencia entre un costo calculado, visto o medido y el costo verdadero,

detallado o teóricamente adecuado.
Fallo: La imposibilidad de un sistema o de alguno de sus elementos para hacer las
funciones requeridas en los requisitos de rendimiento especificados.

Defecto: Un paso, proceso o definición de dato erróneo en un programa de PC. EL

resultado de una equivocación.

Depuración: El proceso de ubicar, examinar y arreglar las deficiencias que se cree que
contiene el programa.

Verificación: Un grupo de ocupaciones que aseguran que el programa

implementa correctamente una funcionalidad específica. (¿Estamos creando el producto
correctamente?).

Validación: Un grupo distinto de ocupaciones que dicen que el programa construido sea
justo a los requisitos del comprador. (¿Estamos creando 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

Documentos Evaluación Relacionados

Casos de pruebas (Plantilla de casos de prueba)
Equipo de Proyecto
Equipo de Arquitecto de
Trabajo
producto
 Visión General Del Documento

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

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)

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.

Cuadro Resumen De Las Pruebas

Modulo del sistema a ser aprobados Módulos:

-Proyectos

-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 con 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

Responsabilidad de la Prueba
-Aprobación
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.

Requerimientos De Pruebas Excluidos

Nombre Descripción Tipo Nivel Criticidad (Bajo-
Medio-Alto)
N/A N/A N/A N/A
Casos De Pruebas Incluidos
# Casos # Estimado Tipo Modulo Total Casos
Disponibles de Casos
Nuevos
150 30 Funcional Proyectos
50 11 Funcional Revisión
45 8 Funcional Aprobación
245

Casos De Pruebas Excluidos

# Casos # Estimado Casos Tipo Modelo
Disponibles Nuevos
N/A N/A N/A N/A

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. Dichos softwares se encontrarán instalados en los equipamientos, debido a
que se va a labora como un servidor local para hacer las pruebas descriptivo
en el punto (a) del ámbito y configuración de las pruebas.

Todos ellos instalados y configurados por los accesorios de trabajo de la compañía

CreApp s.a.s, diseñadores del sistema Resos 1.0.

Criterios De Inicio
Aceptación del plan de pruebas. Revisión y aprobación del archivo que tiene los
casos de pruebas para la certificación del plan.

Aceptación de paquetes. Revisión y aprobación de los paquetes de desarrollo y

que este cumpla con las condiciones de aprobación.

Aceptación de ambiente. Revisión y aprobación del ambiente de certificación y

que este cumpla con las condiciones de aprobación.

Bases De Datos De Pruebas

Administradores de base de datos de, MYSQL
MYSQL es un sistema de administración de bases de datos relacionales
multiplataforma, multiproceso y multiusuario, compartido 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 programa formado por un grupo de herramientas de programación de
código abierto multiplataforma para desarrollar lo cual el plan llama "Aplicaciones de
Comprador Enriquecido", opuesto a las aplicaciones "Cliente-liviano" fundamentadas
en navegadores., utilizada para desarrollar en ámbitos de desarrollo incluidos como el
IDE de JAVA.

Entorno de desarrollo Android Studio

Android Studio es el ámbito de desarrollo incluido (IDE) oficial para el
desarrollo de apps para Android, con base en IntelliJ Iniciativa, Un ámbito unido
donde puedes desarrollar para todos los dispositivos Android.

Spring Source Tool Suite

(STS) es un IDE con base en la versión Java EE de Eclipse, empero enormemente
customizado para trabajar con Spring Framework. En medio de las propiedades más
destacadas que STS proporciona se hallan: Soporte paraSpring3. Asistentes para la
construcción de proyectos Spring, posibilita el desarrollo de Api con Spring Boot.

Postman
 Herramienta que principalmente nos posibilita producir pedidos sobre APIs de una
manera bastante fácil y poder, tal cual, probar las APIs. ... Cerca de la iniciativa de
testear las APIs, Postman nos da un conjunto de utilidades adicional es para poder
gestionar las APIs de una manera más fácil.

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

En caso de ocurrir que el proyecto no

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

Estrategias De Pruebas
Se requiere certificar por parte del equipo de desarrollo y por parte del cliente al
producto Resos 1.0

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:
 El ingreso y la postulación de las propuestas técnicas y sus empleados
asociados.
 La creación, modificación y eliminación de acuerdo con los permisos.
 La revisión y aprobación de los entregables de cada proyecto.
 La visualización, modificación y eliminación del calendario de evaluaciones
y reuniones.
 Que los documentos y actividades se generen con su estado
correspondiente en el sistema.

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.

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:
 Comprensión global del sitio.
 Aspectos de interfaces y estéticos.
 Métricas de confiabilidad.
 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
-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.

Orden De Ejecución De Pruebas

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.

Equipo De Pruebas Y Responsabilidades