ACTIVIDAD SEMANA 3.

SOFTWARE “RECOMENDA PRO”

PRESENTADO POR: ANDREA DEL PILAR AROCA ESCOBAR

CALIDAD EN EL DESARROLLO DE SOFTWARE (2930137)

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, las pruebas a aplicar, según el modelo del ciclo
de vida del
software escogido

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, las pruebas a aplicar, según el
modelo del ciclo de vida del software escogido

Plan de pruebas

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.

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

l modelo de desarrollo de software seleccionado es el modelo en cascada, en
el cual se llevará a cabo de manera secuencial, avanzando de una etapa a la
siguiente solo después de haber completado con éxito las tareas de
verificación y validación específicas de esa etapa. En caso necesario, se
retrocederá únicamente hasta la fase inmediatamente anterior.

ANÁLSIS

DISEÑO

CREACIÓN DE CÓDIGO

PRUEBAS

MANTENIMIENTO

2. Determine el alcance de la prueba:

El plan principal de pruebas para este proyecto consiste en identificar posibles
fallos cometidos en etapas previas del proyecto (y, si es necesario,
 corregirlos), empleando diversas pruebas, herramientas y metodologías
específicas para cada una de estas etapas.

3. Relacione los tipos de pruebas a aplicar:

Pruebas de unidad: Estas pruebas se utilizan para verificar el correcto

funcionamiento de componentes individuales del sistema. Durante estas
pruebas, el evaluador debe explorar situaciones límite que pongan a prueba
las limitaciones de la implementación del componente, ya sea tratándolo como
una caja negra (pruebas de caja negra) o examinando su estructura interna
(pruebas de caja blanca).

Pruebas de integración: Estas pruebas se realizan cuando se van integrando

los componentes del sistema para detectar errores en sus interfaces. Se lleva
a cabo una compilación diaria utilizando los componentes del sistema tal como
están en ese momento (compilación diaria) y se somete al sistema a una serie
de pruebas básicas (prueba de humo) para garantizar que el proyecto pueda
avanzar al día siguiente.

Pruebas alfa: Estas pruebas se realizan desde la perspectiva de un usuario

final y pueden ayudar a mejorar aspectos de la interfaz de usuario del sistema.

4. Analice estrategias de pruebas.

Revisión de la documentación: La estrategia para realizar estas pruebas

implica revisar la documentación y los casos de uso para verificar su integridad
y consistencia en la información que contienen.

Pruebas unitarias: La estrategia para realizar estas pruebas implica generar

casos de prueba necesarios para que cada sentencia o instrucción del
 programa se ejecute al menos una vez correctamente, así como para probar
diferentes escenarios de bucles.

Pruebas funcionales o de procedimientos: La estrategia para realizar estas

pruebas implica la elaboración y ejecución de conjuntos de pruebas,
considerando tanto el flujo normal como los flujos alternativos, utilizando datos
válidos e inválidos para verificar el comportamiento del sistema.

Pruebas de regresión: La estrategia para realizar estas pruebas consiste en

repetir pruebas realizadas previamente (funcionales y de carga) para
comprobar que las modificaciones realizadas no introducen errores nuevos.

Pruebas de aceptación: Estas pruebas se basarán en pruebas funcionales, de

instalación y otras, centrándose en los requisitos funcionales del sistema.
Además, estas pruebas se realizarán como pruebas de caja negra.

Herramientas de pruebas
Técnicas de prueba para minimizar riesgos.

Herramientas de Prueba

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 rol de evaluador
durante sesiones de revisión en las cuales se discutirán los escenarios de calidad
referentes a la usabilidad del software.

Líder: Coordinador del Proceso

Actividades: - Revisión paso a paso del pseudocódigo.<br>- Diseño de Código

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

Descripción: Validar los requerimientos no funcionales del ambiente recolectados
con el cliente versus las características requeridas por el ambiente de producción.

Requerimientos Funcionales
1.GUI
2.Tiempos de respuesta
3. Mensajes

Pruebas de integración
Durante el desarrollo de los componentes de software, las pruebas de
integración se conducirán siguiendo los siguientes principios y directrices:

Antes de iniciar las pruebas de integración, se requiere una fase completa de

pruebas unitarias que haya sido aprobada.

Se comenzará probando individualmente los componentes o módulos del

software. Luego, de manera progresiva, se agruparán funcionalmente estos
componentes, avanzando hacia escenarios que involucren la interacción de
varias funcionalidades. Este proceso continuará hasta alcanzar el nivel más
alto de funcionalidad e integración.

OBJETIVO DE LA Verificar el funcionamiento interno de los componentes

TÉCNICA desarrollados mediante 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 una de estas acciones.
TÉCNICA Pruebas de Caja Negra

ENTRADA SALIDA
PROCESO

HERRAMIENTAS DEPURAR - ROBOT DE PRUEBAS - SEGUIMIENTO DE

VARIABLES
JUICIO DE ÉXITO - Concordancia de los procedimientos del sistema con los
requerimientos de usuario.
- Óptimo manejo de excepciones y errores.
- Fácil seguimiento de la ejecución mediante traces.

OBJETIVO DE LA Verificar que los componentes funcionen correctamente de

TÉCNICA manera individual cuando están integrados con otros
módulos y componentes.
TÉCNICA Pruebas de Regresión

HERRAMIENTAS - DEPURAR - ROBOT DE PRUEBAS - SEGUIMIENTO DE

VARIABLES
JUICIO DE ÉXITO - No se detectan errores inyectados durante la integración
del sistema.

BJETIVO DE LA Verificar que la parametrización de componentes y todos los

TÉCNICA aspectos referentes a la integración de partes del software
(consideraciones, configuraciones, ajustes) cumplan con lo
preestablecido por el equipo de desarrollo en la fase de diseño.
TÉCNICA Listas de Chequeo
HERRAMIENTA Listas de chequeo con los ítems a comprobar para la
S integración
JUICIO DE - El 100% de los ítems han sido chequeados y cumplen con la
ÉXITO condición para ser aprobados

5. Exponga criterios de salida y los aspectos anexos que considere necesario tener
en cuenta
Criterios de Entrada del Plan Maestro de Pruebas:

 Disponibilidad de un set completo y claro de pruebas.

 Claridad en el procedimiento para el desarrollo de las pruebas.
 Disponibilidad de toda la documentación necesaria para realizar las pruebas.

Criterio de Salida del Plan Maestro de Pruebas:

 Ejecución exitosa de todos los sets de pruebas diseñados para cada caso de
uso, cumpliendo con los criterios de aceptación definidos para cada uno.

Suspensión y Reanudación del Plan Maestro de Pruebas:

 Se suspenderá el plan si una característica principal presenta un error que

impide probar un área importante.
 Se suspenderá si el entorno de pruebas no es lo suficientemente estable para
confiar en los resultados.
 Se suspenderá si el entorno de pruebas difiere significativamente del entorno
de producción.
 Se suspenderá si no se puede instalar la nueva versión o un componente
necesario.

Pruebas de Integridad de los datos y Base de datos Objetivo de la Táctica:

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

 Táctica: base de 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

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

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

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

Objetivo de Verificar el registro del medicamento.

la
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 Verificar la correcta modificación el registro del
la 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 Verificar el ingreso de un registro de medicamentos

la 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 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 Verificar que el proceso de compra se lleve a

la 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 Verificar los medicamentos entregados a los

la
Táctica: pacientes
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.
Consideraciones Ninguna
Especiales:

Medicamentos formulados por médicos registro de médicos

Objetivo de Verificar los médicos autorizados a realizar

la 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 Verificar el registro de los médicos registrados.

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

Objetivo de Verificar la correcta modificación el registro del médico.

la
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 Verificar que el médico ha sido bloqueado del

la registro de
Táctica: base 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 de inventario

Objetivo de Verificar los reportes del inventario

la
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

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 Verificar que medicamentos autorizan los médicos

la
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: