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; a su vez, las
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.

Respuestas

1. El modelo de software que se escogió es el modelo en cascada en donde se realizara de forma

secuencial llevando una etapa tras la otra solo 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. 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:

 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").

 Pruebas de integración: se realizan cuando vamos juntando los componentes que conforman
nuestro sistema y sirven para detectar errores en sus interfaces. Realizar 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.

 Pruebas alfa: 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: o Para que cada sentencia o instrucción del programa se ejecute al menos una
vez correctamente. o Para que cada condición tenga por lo menos una vez un resultado verdadero
y al menos una vez uno falso. o 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: o Uso de datos válidos. o 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
software.

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

TÉCNICA

Pruebas de Caja negra

ENTRADA – PROCESO- SALIDA

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 ÉXITO

 El 100% de los ítems han sido chequeados y cumplen con la condición para ser aprobados.

5.  Criterios de Entrada del Plan Maestro de Pruebas o 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 Táctica:

Verificar que los datos ingresados en las tablas de la 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 necesarias:

Copia de Respaldo de la Base de Datos

Criterio de éxito: Retorno y no corrupción de los datos al exponerlos a los procesos funcionales del
sistema.

Consideraciones Especiales: Probar con un mínimo de cinco registros por tabla los 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 Táctica: Verificar el medicamento adicionado a la base de datos.

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

Ninguna.

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

Laboratorio y fecha de vencimiento

Búsqueda de medicamentos.

Objetivo de la Táctica:

Verificar el registro del medicamento.

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 Especiales: Ninguna

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

Objetivo de la Táctica:

Verificar la correcta modificación el registro del inventario.

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 Especiales: Ninguna

Ingreso de medicamentos al inventario realizados por compra

Objetivo de la Táctica:

Verificar el ingreso de un registro de medicamentos por 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 Especiales: Ninguna

compra a proveedores de medicamentos Objetivo de la Táctica:

Verificar que el proceso de compra se lleve a cabo 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 Especiales: Ninguna

Medicamentos entregados a pacientes

Objetivo de la Táctica:

Verificar los medicamentos entregados a los 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 Especiales: Ninguna

Medicamentos formulados por médicos Registro de médicos

Objetivo de la Táctica:

Verificar los médicos autorizados a realizar prescripciones a 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 Especiales: Ninguna

Búsqueda de médicos

Objetivo de la Táctica:

Verificar el registro de los médicos registrados.

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 Especiales: Ninguna

Modificación de médicos.

Objetivo de la Táctica:

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

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 Especiales: Ninguna

Bloqueo de médicos.

Objetivo de la Táctica:

Verificar que el médico ha sido bloqueado del registro de 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 Especiales: Ninguna

Reportes.

Reportes de inventario

Objetivo de la Táctica:

Verificar los reportes del inventario

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 Especiales: Ninguna

Reportes de medico

Objetivo de la Táctica:

Verificar que medicamentos autorizan los médicos

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 Especiales: Ninguna