ACTIVIDAD DE APRENDIZAJE 3

ESTUDIO DE CASO: PRUEBAS DE SOFTWARE

Santa Osorio Luz Stella.

SENA
Formación virtual

CALIDAD EN EL DESARROLLO DE SOFTWARE (1937467)

1
Tabla de contenido
INTRODUCCIÓN ................................................................................................................................... 3
OBJETIVO GENERAL ............................................................................................................................. 4
Actividad 3 ........................................................................................................................................... 5
Estudio de caso: Pruebas de software ................................................................................................ 5
1. Evidencie el modelo, según el ciclo de vida escogido. ................................................................ 6
2. Determine alcance de la prueba. .................................................................................................... 6
3. Relacione los tipos de prueba a aplicar........................................................................................... 6
4. Analice estrategias de pruebas. ...................................................................................................... 7
Pruebas de Aceptación .................................................................................................................... 8
Pruebas de Integración .................................................................................................................... 9
5. Exponga criterios de salida y los aspectos anexos que considere necesario tener en cuenta. .... 11
 Criterios de Entrada del Plan Maestro de Pruebas ................................................................ 11
 Suspensión y Reanudación .................................................................................................... 11

2
INTRODUCCIÓN

Con esta actividad logramos competencias cognitivas para abordar los conceptos,
propósitos, metodología, estrategias y pruebas a realizar en el proceso y construcción del
software.

3
OBJETIVO GENERAL

Analizar y aplicar los conceptos básicos dados en el proceso de pruebas y construcción del
software.

4
Actividad 3

Estudio de caso: Pruebas de software

La empresa SoftSena, especializada en desarrollo de software, ha sido requerida por una

clínica de salud, la cual ha presentado el requerimiento de desarrollar un sistema de
información tradicional (de escritorio), donde se registren los medicamentos entregados a
los pacientes, los formulados por los médicos y los que se compran a los proveedores.
De igual forma la empresa requiere conocer el estado de inventario de los medicamentos
por laboratorio. El sistema debe permitir generar todos los reportes necesarios de acuerdo a
los requerimientos diarios, semanales y mensuales.

Por tal motivo, se solicita la asesoría de un profesional en este campo.

El grupo técnico para la construcción del proyecto ya está conformado. Sin embargo, se
enfrenta a la decisión de

Escoger el modelo de software que orientará el diseño y construcción y a su vez,

Pruebas a aplicar, según el modelo del ciclo de vida del software escogido.
Realizar un plan de pruebas en un documento en formato Word, en el cual:
1. Evidencie el modelo, según el ciclo de vida escogido.
2. Determine alcance de la prueba.
3. Relacione los tipos de prueba a aplicar.
4. Analice estrategias de pruebas.
5. Exponga criterios de salida y los aspectos anexos que considere necesario tener en
cuenta.

DESARROLLO

5
 1. Evidencie el modelo, según el ciclo de vida escogido.

El modelo de software seleccionado que orientará el diseño y construcción del ciclo de vida
requerido para la clínica será el clásico, también denominado "modelo en cascada", se basa
en intentar hacer las cosas bien desde el principio, de una vez y para siempre. Se pasa, en
orden, de una etapa a la siguiente sólo tras finalizar con éxito las tareas de verificación y
validación propias de la etapa. Si resulta necesario, únicamente se da marcha atrás hasta la
fase inmediatamente anterior.

2. Determine alcance de la prueba.

El plan maestro de pruebas para este proyecto es detectar los errores que se hayan podido
cometer en las etapas anteriores del proyecto (y, eventualmente, corregirlos). Aplicando
diferentes pruebas, herramientas y metodologías en cada una de estas etapas.

3. Relacione los tipos de prueba a aplicar.

En la búsqueda de errores en este proyecto aplicaremos pruebas tales como:

6
Las pruebas de unidad sirven para comprobar el correcto funcionamiento de un
componente concreto de nuestro sistema. Es este tipo de pruebas, el "probador" debe buscar
situaciones límite que expongan las limitaciones de la implementación del componente, ya
sea tratando éste como una caja negra ("pruebas de caja negra") o fijándonos en su
estructura interna ("pruebas de caja blanca"). Resulta recomendable que, conforme vamos
añadiéndole nueva funcionalidad a nuestras aplicaciones, vayamos creando nuevos tests
con los medir nuestro progreso y también repitamos los antiguos para comprobar que lo que
antes funcionaba sigue funcionando (test de regresión).

Las pruebas de integración son las que se realizan cuando vamos juntando los
componentes que conforman nuestro sistema y sirven para detectar errores en sus
interfaces.Rrealizar una compilación diaria utilizando los componentes del sistema tal
como estén en ese momento (daily build) y se somete al sistema a una serie de pruebas
básicas (la prueba de humo, smoke test) que garanticen que el proyecto podrá seguir
avanzando al día siguiente. El causante de que la compilación diaria falle suele tener que
quedarse a hacer horas extra para que sus compañeros puedan seguir trabajando al día
siguiente...

- Una vez "finalizado" el sistema, se realizan pruebas alfa en el seno de la organización

encargada del desarrollo del sistema. Estas pruebas, realizadas desde el punto de vista de un
usuario final, pueden ayudar a pulir aspectos de la interfaz de usuario del sistema

4. Analice estrategias de pruebas.

El plan de pruebas se basará en su totalidad en pruebas funcionales, instalación, regresión y

otras teniendo en cuenta los requerimientos no funcionales.
Revisión de la documentación: La estrategia para realizar estas pruebas, consiste en la
revisión de la documentación y casos de uso verificando su completitud y concordancia
en la información que se encuentra en ellos.
 Pruebas unitarias: Las estrategias para realizar estas pruebas consiste en generar
casos de prueba necesarios:
 Para que cada sentencia o instrucción del programa se ejecute al menos una vez
correctamente.

7
  Para que cada condición tenga por lo menos una vez un resultado verdadero y al
menos una vez uno falso.
 Para probar varias veces el mismo bucle (en donde aplique) considerando los
siguientes casos: Ignorar el bucle, pasar una vez, pasar dos veces, pasar n veces,
pasar n-1 veces y n+1 veces.

 Pruebas funcionales o de procedimientos: La estrategia para realizar estas pruebas

consiste en la elaboración y ejecución de Set de Pruebas, teniendo en cuenta flujo
normal y flujos alternativos, usando datos validos e inválidos que permitan verificar lo
siguiente:
- Uso de datos válidos.
- Uso de datos inválidos.

 Pruebas de Regresión: La estrategia para realizar estas pruebas consiste en repetir las
pruebas (funcionales y de carga) ejecutadas antes de corregir defectos o de añadir
nuevas funcionalidades, para comprobar que las modificaciones no provocan errores
donde antes no los había.

 Pruebas de Aceptación Las pruebas de aceptación se basarán en su totalidad en

pruebas funcionales, instalación, y otras teniendo en cuenta los requerimientos
funcionales las pruebas. Adicionalmente estas pruebas serán de caja negra.

 Pruebas funcionales o de procedimientos: La estrategia para realizar estas pruebas

consiste en la elaboración y ejecución de Set de Pruebas, teniendo en cuenta flujo
normal y flujos alternativos, usando datos validos e inválidos que permitan verificar los
casos de pruebas.

HERRAMIENTAS DE PRUEBA

Herramientas técnicas para las pruebas enfocadas en la reducción de riegos.

Factor de Prueba: Conformidad Técnica: Pruebas de operación

Descripción:
Con las pruebas de operación se garantiza que el usuario está bien capacitado en el manejo
del software y además se lleva un registro para guardar los caminos no contemplados
dentro de las pruebas previas del software, y con ello se tomarán las medidas adecuadas.

Factor de Prueba: Facilidad de Uso Técnica: Revisiones

Descripción:
Se debe incluir al cliente y/o usuario final con un role de evaluador durante sesiones de
revisión en las cuales se discutirán los escenarios de calidad referentes a la usabilidad del

8
software.

Líder: Coordinador Proceso:

Diseño Código - Revisión pasó a paso pseudo
código.

Factor de Prueba: Facilidad de Operación Técnica: Pruebas de Requerimientos

Descripción:
Validar los requerimientos no funcionales de ambiente recolectados con el cliente versus
las características requeridas por el ambiente de producción.
Requerimientos funcionales:
- GUI
- Tiempos de respuesta.
- Mensajes.

Pruebas de Integración
Las pruebas de integración que se realizaran durante el proceso de desarrollo de los
componentes de software, deben seguir las siguientes políticas y lineamientos de ejecución:

 Se tiene una fase de pruebas unitarias competa y aprobada para el inicio de las pruebas
de integración.
 Probar en primer lugar los componentes o módulos individuales del software y
posteriormente y de manera progresiva se Irán agrupando hacia arriba y de manera
funcional estos componentes para probar escenarios que impliquen varias
funcionalidades de interacción entre los componentes, y se continuará así hasta llegar al
nivel más alto de funcionalidad e integración.
 Para la ejecución de estas pruebas se utilizarán las siguientes técnicas:

OBJETIVO DE LA TECNICA
Verificar el funcionamiento interno de los componentes desarrollados por medio de la
comprobación de los procedimientos llevados a cabo por el software en cada
invocación/llamado/respuesta, así como el procesamiento de datos que tiene lugar en cada
uno de esta acciones.
TÉCNICA

9
 Pruebas de Caja negra
ENTRADA SALIDA
PROCESO

HERRAMIENTAS
- DEPURAR - ROBOT DE PRUEBAS - SEGUIMIENTO DE VARIABLES
JUICIO DE EXITO
* Concordancia de los procedimientos del sistema con los requerimientos de usuario
 Optimo manejo de excepciones y errores
 Fácil seguimiento de la ejecución por medio de los traces.

OBJETIVO DE LA TECNICA
Verificar que los componentes funcionen adecuadamente de manera individual cuando se
encuentran integrados con otros módulos y componentes
TÉCNICA
Pruebas de Regresión
HERRAMIENTAS
- DEPURAR - ROBOT DE PRUEBAS - SEGUIMIENTO DE VARIABLES
JUICIO DE EXITO
 No se detectan errores inyectados durante la integración del sistema

OBJETIVO DE LA TECNICA
Verificar que la parametrización de componentes y todos los aspectos referentes a la
integración de partes del software (consideraciones, configuraciones, ajustes) cumplan con
lo preestablecido pro el equipo desarrollo en la fase de diseño.
TÉCNICA
Listas de Chequeo
HERRAMIENTAS
Listas de chequeo con los ítems a comprobar para la integración
JUICIO DE EXITO
 El 100% de los ítems han sido chequeados y cumplen con la condición para ser
aprobados.

10
5. Exponga criterios de salida y los aspectos anexos que considere
necesario tener en cuenta.

 Criterios de Entrada del Plan Maestro de Pruebas

- Set de pruebas completo y claro.

- Claridad en el procedimiento para el desarrollo de las pruebas.
- Toda la documentación requerida para la realización de las pruebas debe estar
- disponible.

 Criterio de Salida del Plan Maestro de Pruebas

- Que todos los sets de pruebas diseñadas para cada caso de uso se ejecuten de
manera exitosa, cumpliendo los criterios de aceptación definidos para cada uno.

 Suspensión y Reanudación
- Una característica principal tiene un error que impide probar un área importante.
- El entorno de pruebas no es lo suficientemente estable como para confiar en los
resultados.
- El entorno de pruebas es muy diferente del entorno de producción.
- No se puede instalar la nueva versión o un componente

Pruebas de Integridad de los datos y Base de datos

Objetivo de la Verificar que los datos ingresados en las tablas de la base de

Táctica: datos no sufran.
Verificar la integridad referencial de los datos.
Táctica: Invocar cada acceso a la base de datos por medio de los
procesos y métodos definidos; enviando datos válidos e
inválidos.
Verificar que cada proceso ocurra de manera correcta y que se
retornen los datos esperados en cada caso específico.

11
Herramientas Copia de Respaldo de la Base de Datos
necesarias:

Criterio de éxito: Retorno y no corrupción de los datos al exponerlos a los

procesos funcionales del sistema.
Consideraciones Probar con un mínimo de cinco registros por tabla los
Especiales: procesos.
Todos los procesos serán invocados manualmente.

PRUEBAS DE FUNCIONAMIENTO:

1. Inventario de medicamentos por laboratorio y fecha de vencimiento

2. Compra a proveedores
3. Medicamentos entregados a pacientes
4. Medicamentos formulados por los médicos
5. Reportes

 Inventario de medicamentos por laboratorio y fecha de vencimiento

Registro de medicamentos:

Objetivo de la Verificar el medicamento adicionado a la base de datos.

Táctica:
Táctica:  Por medio del formulario de Registro de medicamentos
ingresar en los campos los datos solicitados y presionar el
botón de Grabar registro.
 Se enviarán datos incorrectos en los campos para verificar
que los avisos de información inválida sean mostrados.
Herramientas Ninguna.
necesarias:
Criterio de éxito: Se revisará la tabla de inventario de medicamentos de la base
de datos y se verificará que el registro diligenciado en el
formulario haya sido adicionado correctamente.
En caso de enviar datos inválidos el registro no debe haber sido
adicionado a la tabla de inventario.
Consideraciones Laboratorio y fecha de vencimiento
Especiales:

Búsqueda de medicamentos.
12
Objetivo de la Verificar el registro del medicamento.
Táctica:
Táctica:  Por medio del formulario de Registro de medicamentos se
podrán buscar registros de la base de datos.
Si no se encuentran registrados avisara por medio de un
mensaje.
Criterio de éxito: En el formulario de Registro de medicamentos, se debe
cargar la información del registro completo encontrado.
En caso de enviar datos inválidos el motor de búsqueda no
cargará ningún registro en el formulario de Registro de
inventario.
Consideraciones Ninguna
Especiales:

Modificación del inventario por salida de medicamentos o vencimiento.

Objetivo de la Verificar la correcta modificación el registro del inventario.

Táctica:
Táctica:  Por medio del formulario de Registro de inventario se
podrán Modificar registros de la base de datos.

Criterio de éxito: En el formulario de Registro de inventario, se debe cargar la

información del registro completo encontrado.
En caso de enviar datos inválidos el motor de búsqueda no
cargará ningún registro en el formulario de Registro de
Personal.
Consideraciones Ninguna
Especiales:

Ingreso de medicamentos al inventario realizados por compra

Objetivo de la Verificar el ingreso de un registro de medicamentos por

Táctica: compra se ejecute correctamente.
Táctica:  Una vez se ubique el registro de compra por medio de la
función “Búsqueda de compra” descrita anteriormente. Se
presionará el botón “anexar”.

Criterio de éxito: Se revisará la tabla de Registro de inventario de la base de

13
 datos y se verificará que el registro haya sido anexado a la base
de datos.
Consideraciones Ninguna
Especiales:

 compra a proveedores de medicamentos

Objetivo de la Verificar que el proceso de compra se lleve a cabo

Táctica: exitosamente.
Táctica:  Por medio del formulario de pedido y factura de venta se
realizan la verificación de la compra

Criterio de éxito: Se revisará la tabla de compra a proveedores de la base de

datos y se verificará que el registro diligenciado en el
formulario haya sido adicionado correctamente.
En caso de enviar datos inválidos el registro no debe haber sido
adicionado a la tabla de compra a proveedores
Consideraciones Ninguna
Especiales:

 Medicamentos entregados a pacientes

Objetivo de la Verificar los medicamentos entregados a los pacientes

Táctica: adicionado a la base de datos médico tratante.
Táctica:  Por medio del formulario de entrega de medicamentos
ingresar en los campos los datos solicitados y presionar el
botón de Grabar registro.
 Se enviarán datos incorrectos en los campos para verificar
que los avisos de información inválida sean mostrados.
Criterio de éxito: Se revisará la tabla de entrega de medicamentos e inventario
de la base de datos y se verificará que el registro diligenciado
en el formulario haya sido adicionado correctamente.
En caso de enviar datos inválidos el registro no debe haber sido
adicionado a la tabla de Cargos.

14
Consideraciones Ninguna
Especiales:

 Medicamentos formulados por médicos

Registro de médicos

Objetivo de la Verificar los médicos autorizados a realizar prescripciones a

Táctica: pacientes
Táctica:  Por medio del formulario se registran los médicos
autorizados a realizar prescripciones de medicamentos.
 Se enviarán datos incorrectos en los campos para verificar
que los avisos de información inválida sean mostrados.
Criterio de éxito: Se revisará la tabla de registro de médico en la base de datos y
se verificará que el registro diligenciado en el formulario haya
sido adicionado correctamente.
En caso de enviar datos inválidos el registro no debe haber sido
adicionado a la tabla de registro de médico.
Consideraciones Ninguna
Especiales:

Búsqueda de médicos

Objetivo de la Verificar el registro de los médicos registrados.

Táctica:
Táctica:  Por medio del formulario de registro de médico se podrán
buscar registros de la base de datos.
Si no se encuentran registrados avisara por medio de un
mensaje.
Criterio de éxito: En el formulario de Cargos, se debe cargar la información del
registro completo encontrado.
En caso de enviar datos inválidos el motor de búsqueda no
cargará ningún registro en el formulario de Cargos.
Consideraciones Ninguna
Especiales:

Modificación de médicos.

15
Objetivo de la Verificar la correcta modificación el registro del médico.
Táctica:
Táctica:  Por medio del formulario de registro de médicos se podrán
Modificar registros de la base de datos.

Criterio de éxito: En el formulario de registro de médicos, se debe cargar la

información del registro completo encontrado.
En caso de enviar datos inválidos el motor de búsqueda no
cargará ningún registro de médico, avisando por medio de un
mensaje.
Consideraciones Ninguna
Especiales:

Bloqueo de médicos.

Objetivo de la Verificar que el médico ha sido bloqueado del registro de base

Táctica: de datos
Táctica:  Una vez se ubique el registro a bloquear por medio de la
función “Búsqueda de medico” descrita anteriormente. Se
presionará el botón “bloquear”.

Criterio de éxito: Se revisará la tabla de médicos de la base de datos y se

verificará que el registro haya sido bloqueado de la base de
datos.
Consideraciones Ninguna
Especiales:

Reportes.

Reportes de inventario

Objetivo de la Verificar los reportes del inventario

Táctica:
Táctica:  Una vez se ubique el registro inventario de medicamentos
descrita anteriormente Se presionará el botón “copiar”
“imprimir”.
Estos reportes se pueden solicitar a el tiempo deseado

16
Criterio de éxito: Se revisará la tabla de reporte de la base de datos y se
verificará que el registro haya generado correctamente
especificando laboratorio y fecha de vencimiento.
Consideraciones Ninguna
Especiales:

Reportes de medico

Objetivo de la Verificar que medicamentos autorizan los médicos

Táctica:
Táctica:  Una vez se ubique el registro de médicos descrita
anteriormente se genera la información de medicamentos
enviados. Se presionará el botón “copiar” “imprimir”.
Estos reportes se pueden solicitar a el tiempo deseado
Criterio de éxito: Se revisará la tabla de médicos de la base de datos y se
verificará que el registro haya generado correctamente.
Consideraciones Ninguna
Especiales:

17