TALLER 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, las pruebas a aplicar, según el modelo del ciclo de vida del
software escogido.
Teniendo en cuenta lo anterior, el Aprendiz deberá 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.

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 "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 poder corregirlos.
Aplicando diferentes pruebas, herramientas y metodologías en cada una de estas
etapas.

3. Relacione los tipos de prueba aplicar:

En la búsqueda de errores en este proyecto se aplicarían las siguientes pruebas:

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 test con tal de
medir nuestro progreso y también repitamos los antiguos para comprobar que lo
que antes funcionaba siga funcionando de la manera adecuada.

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. Realizar una compilación diaria utilizando los componentes del
sistema tal como estén y se somete al sistema a una serie de pruebas básicas
por ejemplo la prueba de humo, 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 prueba.

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

1. Uso de datos válidos.

2. 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 enfocas en la reducción de riesgos.
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 conformidad Técnica: Pruebas de
prueba: operación
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.

Líder de coordinación Proceso: Revisión paso a paso del código

DISEÑO CODIGO

Factor de prueba: Conformidad Técnica: Pruebas de

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

4
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 AS DE PRUEBA
Herramientas técnicas para las pruebas
enfocadas en la reducción de riegos.
Factor de
Prueba:
Conformidad Técnica: Pruebas de
opera
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:
Fa
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.
Líder: coordinador
Diseño Código
Proceso: Revisión paso a paso del código
Fa
Requerimientos funciónales:
 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 variar
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.
TECNICA
Pruebas de caja negra

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

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

táctica: 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.
Consideracione Probar con un mínimo de cinco registros por tabla los
s 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.

Consideracione Laboratorio y fecha de vencimiento.

s especiales:

Búsqueda de medicamentos.

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.
Consideracione Ninguna
s especiales:

Modificación de inventario por salida de medicamentos o vencimientos.

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.

Consideracione Ninguna.
s especiales:

Ingreso de medicamentos al inventario realizados por la 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 datos y

se verificará que el registro haya sido anexado a la
Base de datos.

Consideracione Ninguna
s 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
Consideracione Ninguna
s especiales:

 Medicamentos entregados a pacientes

Registro de médicos

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
Consideracione Ninguna
s 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.
Consideracione Ninguna
s especiales:

Modificación de médicos

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.

Consideracione Ninguna
s especiales:

Bloqueo de médicos

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

Consideracione Ninguna
s especiales:

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

Consideracione Ninguna
s 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.

Consideracione Ninguna
s especiales: