AP09-AA10-EV02.

DISEÑO Y EJECUCIÓN DE PLAN DE PRUEBAS DEL

SISTEMA DE INFORMACIÓN.

CRISTIAN GAMEZ
DIEGO HUERTAS
ISMAEL CARVAJAL
WALTER TOSCANO

INSTRUCTORA
ALEXANDRA SORAYA BELTRÁN CASTRO

ANÁLISIS Y DESARROLLO DE SISTEMA DE INFORMACIÓN (2282261)

2022
 INTRODUCCIÓN

Este plan de pruebas describe el enfoque de las pruebas y el marco

general que se utilizara para la página web CLIO versión 1.0. Una
aplicación desarrollada para realizar un registro y administración de citas
para una clínica odontológica, en el documento se presentara los
diferentes módulos y casos que se abordaron para hacer las pruebas
como lo son las pruebas unitarias y las funcionales, de acuerdo con la
lineamientos de las normas ISO/29119.
ALCANCE DE LAS PRUEBAS DEL SISTEMA DE INFORMACIÓN

Las pruebas incluyen todas las funcionalidades de los cinco módulos de ‘CLIO-
Clínica Odontológica’. En estos módulos se realizarán pruebas funcionales y no
funcionales para los distintos niveles de prueba y además en cuanto a pruebas no
funcionales se aplicarán pruebas para validar el rendimiento y usabilidad de dicho
componente.

Las pruebas de rendimiento serán desarrolladas por el QA de performance, la

prueba de usabilidad será desarrollada por el QA manual y las pruebas
funcionales serán repartidas entre el QA manual y el QA automación.

Además de lo anterior, también se practicarán pruebas unitarias y de integración

por parte de todo el equipo. (Tomado del plan de pruebas del sistema de
información CLIO)

Pruebas funcionales:

- Durante las pruebas funcionales, el equipo de pruebas creara los

respectivos datos de cada módulo y ejecutara las pruebas
- El equipo de pruebas realizara las pruebas en los módulos de pacientes,
Odontólogos y turnos del sistema de información CLIO.

GLOSARIO

Error: resultante que no cumple con condiciones idóneas para la buena

ejecución o no da la respuesta deseada

Depuración: Proceso mediante el cual se identifica o corrigen errores

Casos de prueba: condiciones o variables para determinar si una

aplicación se ejecuta a satisfacción

Verificación: proceso que se realiza para constatar o comprobar el estado

de una ejecución

Prueba: evaluación mediante la ejecución de proyectos, por medio de la

verificación de resultados, fallos, errores y corrección de los mismos
 Validación: confirmación de respuesta de un método dándole aceptación
al mismo

Fallo: es una consecuencia al ser ejecutado un proceso y no dar

respuesta satisfactoria, un daño.

VISIÓN GENERAL DEL DOCUMENTO:

Todos sabemos que el proceso de desarrollo de software implica varias

fases. Desde el desarrollo hasta la producción, el software debe pasar
por varias fases en las que evoluciona. Sin embargo, hay una etapa
que, por su propia naturaleza, no merece la publicidad que podría
recibir. A pesar de que se reconoce la importancia y la necesidad de las
pruebas, en muchos casos éstas se hacen mal o no se hacen. Las
pruebas son esencialmente un conjunto de actividades de desarrollo de
software. Dependiendo del tipo de pruebas, estas actividades pueden
tener lugar en cualquier fase del proceso de desarrollo. Existen
diferentes modelos de desarrollo de software y diferentes modelos de
pruebas. Cada uno de ellos corresponde a un nivel diferente de
participación en las actividades de desarrollo. El aseguramiento de la
calidad del software utiliza aplicaciones que permiten realizar extensas
pruebas "fuera de línea", proporcionando pruebas estáticas y de "caja
blanca", es decir, pruebas que analizan el software sin ejecutar el código
fuente.

DESCRIPCIÓN DEL AMBIENTE DE PRUEBAS (PRECONDICIONES Y

POSTCONDICIONES)

Los ambientes de prueba tendrán las siguientes configuraciones de

Software:

• Maven con una versión 4.0.0: Es un gestor de dependencias.

• Git con una versión 2.36.1: Es un sistema de versionamiento
• Java con la versión 18: Es un lenguaje de programación
• Postman con la versión 9.4: Es un probador de API’s
• Karate con la versión 2.2.3: Es un framework de automatización de pruebas
• Test Assured con la versión 3.0.2.3: Es un framework escrito en Java y
diseñado para simplificar las pruebas sobre servicios basados en REST).

PRUEBAS UNITARIAS:
 Version
fecha Autor Descripción de cambios

15/08/20 Diego Alejandro

1 22 Huertas Revisado

Objetivo de la prueba: Aislar cada parte del programa y demostrar que las partes
individuales son correctas. Dar un fragmento de código.

PRUEBA DE INTEGRACIÓN DE MÓDULO ODONTÓLOGO:

RESULTADOS DE LAS PRUEBAS DE INTEGRACIÓN ODONTÓLOGO:
PRUEBAS UNITARIAS ODONTÓLOGOS:

RESULTADOS PRUEBAS UNITARIAS ODONTÓLOGO:

PRUEBAS DE INTEGRACIÓN DE PACIENTES:

RESULTADOS DE PRUEBAS DE INTEGRACIÓN DE PACIENTES:

PRUEBAS DE INTEGRACIÓN DE PACIENTES:

RESULTADOS DE PRUEBAS DE INTEGRACIÓN DE PACIENTES:

PRUEBAS DE INTEGRACIÓN DE TURNOS:

RESULTADOS DE PRUEBAS DE INTEGRACIÓN DE TURNOS:

 REGISTRO DE RESULTADOS DE LAS PRUEBAS UNITARIAS

Nombre Rol Aprobador/revisor Fecha de

aprobación
Walter Alejandro T Administrador 100% 15/08/2022
Ismael Carvajal G Desarrollador 100% 17/08/2022
Diego Huertas Desarrollador 100% 14/08/2022

REGISTRO DE PRUEBAS DE INTEGRACIÓN:

Versión Fecha Descripción

1.0 20/08/2022 Módulo de pacientes,
Odontólogos y turnos

ALCANCE Y NIVELES DE LAS PRUEBAS EXPLORATORIAS:

PROPÓSITO: el propósito de esta prueba es asegurarse de que los defectos críticos se

eliminan antes de que los siguientes niveles de prueba puedan comenzar.

ALCANCE: Navegación de primer nivel, módulos de concesionario y de administración.

TESTERS: Equipo de pruebas.

MÉTODO: esta prueba exploratoria se lleva a cabo en la aplicación sin scripts de prueba ni
documentación.

PRUEBA FUNCIONAL

OBJETIVO: las pruebas funcionales se realizan para comprobar las funciones de la

aplicación.

Las pruebas funcionales se llevan a cabo alimentando la entrada y validando la salida de

la aplicación.

ALCANCE: La siguiente hoja de Excel detalla el alcance de la prueba funcional.

Nota: El alcance es de alto nivel debido a los cambios en los requisitos.

TESTERS: Equipo de pruebas.

MÉTODO: La prueba se realizará de acuerdo con los scripts funcionales, que se

almacenan en
CLIO
CRITERIOS DE ACEPTACIÓN DE LA PRUEBA

Las pruebas del equipo de testing comenzarán cuando hayan pasado satisfactoriamente
las pruebas unitarias.

El criterio de finalización de las pruebas será cuando se hayan ejecutado todas las
pruebas planificadas o, si el tiempo apremia, al menos se hayan ejecutado los casos de
prueba de prioridad alta y media.

El criterio para pasar a producción será que no haya errores bloqueantes o críticos sin
resolver.

RESULTADOS DE LAS PRUEBAS

Numero Descripción Autor Resultado

1 Plan de Pruebas Jefe de Prueba Ejecutado
2 Casos de pruebas Jefe de Prueba Ejecutado
funcionales
3 Registro de defectos Jefe de Prueba Ejecutado

RIESGOS DE LAS PRUEBAS Y FACTORES DE MITIGACIÓN

No Riesgos Probabilidad Impacto Severidad Plan de

Mitigación
(1-5) (1-5) (Prob*Impct)

1 Retrasos en la 2 5 10 Evaluar el
implementación de las avance del
desarrollo de las
funcionalidades. funcionalidades y
re-planificar
acorde al avance
de ser necesario.

2 Los usuarios no están 1 5 5 Coordinar con

listos para las pruebas las oficinas
centrales la
selección
 de aceptación (UAT) temprana de los
usuarios.

AJUSTES Y RECOMENDACIONES

A continuación, presentaremos una serie de recomendaciones y

ciertos ajustes para el buen funcionamiento del sistema de
información:

1-. Verificar que el sistema se encuentre conectado a la base de datos.

2- Reactivar base de datos en caso de que está se encuentre desactivada.

3- Insertar datos correctamente en los módulos.

ANEXOS.

Normativa Aplicada
 Estándares ISO 20000:2013 e ISO 27001:2015
 Ley 1581 protección de datos personales
 Decreto 1377 de 2013

BIBLIOGRAFÍA
[1] a. d. p. d. software, «Tutorial Del Plan De Prueba: Una Guía Para Escribir Un
Documento De Plan De Prueba De Software Desde Cero,» [En línea]. Available:
https://www.softwaretestinghelp.com/how-to-write-test-plan-document-software-testing-
training-day3/#.