Está en la página 1de 15

CALIDAD EN EL DESARROLLO DE SOFTWARE

Estudio de caso. Pruebas de software

PRESENTADO POR:
ING. JAHIR HINCAPIE OLAVARRIA

PRESENTADO A:
HEIDY ALEJANDRA CELIS TRUJILLO

SERVICIO DE APRENDIZAJE – SENA


FORMACIÓN VIRTUAL
CALIDAD EN EL DESARROLLO DE SOFTWARE
UNIDAD 3
SANTA MARTA
2020
EVIDENCIA 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

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

El modelo de software que hemos seleccionado en este trabajo que estará


enfocado en el diseño y construcción del ciclo de vida para la Clínica será el
CLASICO, también este es denominado modelo de cascada, este modelo es muy
interesante porque plantea de que desde el inicio del proyecto evoca hacer las
cosas muy bien y hasta el final de la entrega del producto.
Este modelo solo pasa a la etapa siguiente sin antes haber finalizado la anterior, y
así en su orden, ósea, después de haber terminado la etapa de verificación de una
etapa es ahí cuando se pasa a la siguiente. Si se puede dar marcha atrás solo si
es necesario.

Imagen1: Etapas del modelo de cascada.1

2. Determine alcance de la prueba.

1
Tomado de https://n9.cl/jf1e
En nuestro Plan maestro de pruebas para este proyecto tenemos determinado
encontrar todos los errores que se hayan encontrado al momento de hacer las
pruebas pertinentes, e irlas corrigiendo para que todo fluya de la mejor manera y
no se pierda tiempo, puesto que hay que cumplir un cronograma.

 Relacione los tipos de prueba a aplicar.

En este proyecto, aplicaremos varias tipos de pruebas con el fin de detectar los
errores que se hayan cometido en cada etapa finalizada. Algunas de las pruebas
las mencionaremos a continuació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.2

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

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

2
Tomado de http://portafolio-g6.weebly.com/capiacutetulo-7.html
3
Ibíd.
4
Ibíd.
 Analice estrategias de pruebas.

Todo el Plan de pruebas como su nombre lo dice, PRUEBAS, ósea que se basara
en su totalidad de pruebas y todas funcionales, instalación, regresión y otras a
según los requerimientos funcionales de lo que se vaya a probar.
Revisión de la documentación: en esta parte es mirar la documentación, ver su
concordancia de la información que en ellos esta depositada.
 Pruebas unitarias: estas se dan cuando se generan casos de pruebas
necesarios:

 En el programa habrá sentencias o instrucción que se ejecute al menos


una sola vez correctamente.
 Para que cada condición tenga por lo menos una vez un resultado
verdadero y al menos una vez uno falso.
 Hay que probar varias veces el mismo bucle (en donde sea necesario)
teniendo en cuenta estos 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: para hacer esta prueba, lo mejor


es realizar pruebas que 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 inválidos.


o Uso de datos válidos.

 Pruebas de Regresión: consiste en repetir la prueba (funcionales y de carga)


hechas antes de mejorar los defectos o hasta no añadir nuevas
funcionalidades, esto con el fin de comprobar que lo que se haya modificado
no siga arrojando errores donde había.

 Pruebas de Aceptación: estas son totalmente funcionales, instalación y otras.


Se tiene que tener en cuenta los requerimientos funcionales las pruebas.
Adicionalmente estas pruebas serán de caja negra.
 Pruebas funcionales o de procedimientos: aquí es elaborar y ejecutar un
Set de Pruebas, no olvidando el flujo normal y flujos alternativos, teniendo en
cuenta que los datos deben ser datos validos e inválidos que permitan verificar
los casos de pruebas.
Herramientas de la prueba.

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

Factor de Pruebas de
Conformidad Técnica:
Prueba: operación
Descripción: Las pruebas de operación se asegura que el usuario está bien
capacitado en el manejo del software y tanto así que se llevara un registro para
guardar los caminos no contemplados dentro de las pruebas previas del software,
y con esto se busca que se tomen las mejores medidas que convengan.

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

Descripción: durante las sesiones de revisión, se debe incluir un rol de evaluador


al cliente final, esto con el fin de tratar temas de calidad referente al software.

Líder: Coordinador Proceso:


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

Factor de Facilidad de Pruebas de


Técnica:
Prueba: Operación Requerimientos

Descripción: aquí se validaran los requerimientos no funcionales de ambiente,


recolectados con el usuario contra el ambiente de producción requerido.

Requerimientos funcionales:
- GUI
- Tiempos de respuesta.
- Mensajes.

Pruebas de Integración: durante el proceso de desarrollo de los componentes


que tendrá el software, se realizara pruebas de integración durante estos procesos
y estas deben seguir unos lineamientos políticos y de ejecución los cuales
mencionaremos a continuación.

 Se tiene una fase de pruebas unitarias competa y aprobada para el inicio de


las pruebas de integración.
 Para la ejecución de estas pruebas se utilizarán las siguientes técnicas:
 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.

OBJETIVO DE LA TECNICA
Verificar todo el funcionamiento interno de los componentes desarrollados por
medio de la comprobación de todos los procedimientos que realiza el software en
cada invocación/llamado/respuesta, teniendo en cuenta el procesamiento de datos
teniendo que tiene lugar en cada uno de esta acciones.
TÉCNICA
Pruebas de Caja negra
ENTRADA SALIDA
PROCESO

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

OBJETIVO DE LA TECNICA
Verificar que todos los componentes funcionen óptimamente y de esta 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 ÉXITO
 No se detectan errores inyectados durante la integración del sistema
OBJETIVO DE LA TECNICA
Verificar que la parametrización de todos los componentes y los aspectos que
tienen que ver con la integración de partes del software (consideraciones,
configuraciones, ajustes) cumplan a cabalidad con lo preestablecido en pro el
equipo desarrollo en la fase de diseño del software.
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.

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


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

 Criterio de Salida del Plan Maestro de Pruebas

- Que todos los sets de las pruebas diseñadas para cada caso de uso se hagas
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

Verificar que los datos ingresados a las bases de datos no


Objetivo de la se alteren.
Táctica:
Verificar la integridad y seguridad referencial de los datos.
Invocar cada acceso que se le haga a la base de datos por
medio de los procesos y métodos definidos; enviando datos
válidos e inválidos.
Táctica:
Verificar que los procesos que se le pidan se haga de la
manera correcta y retorne datos esperados sin
equivocaciones.
Herramientas
Que se haga un Backup de la base de Datos
necesarias:
Retorno y no corrupción de los datos al exponerlos a los
Criterio de éxito:
procesos funcionales del sistema.
Probar con un mínimo de cinco registros por tabla los
Consideraciones procesos.
Especiales:
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 que todos los medicamentos ingresados a la clínica


Táctica: sean ingresados a la base de datos.
Por medio del formulario de Registro de medicamentos:
 Ingresar en los campos los datos solicitados.
Táctica:  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:
Se revisará la tabla de inventario de medicamentos de la
base de datos y se actualizara el inventario si este fue
Criterio de éxito: ingresado 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 la
Verificar el registro del medicamento.
Táctica:
Por este formulario de Registro de medicamentos se podrán
si está en la base de datos.
Táctica:
Si no se encuentran en la base de datos registrados el
programa arrojara un mensaje de aviso.
En el formulario de Registro de medicamentos, se debe
cargar la información del registro completo encontrado.
Criterio de éxito: 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 que la modificación del registro del inventario haya


Táctica: sido correcta.
Por medio del formulario de Registro de inventario se
Táctica:
podrán Modificar registros de la base de datos.
En el formulario de Registro de inventario, se debe cargar
la información del registro completo encontrado.
Criterio de éxito: 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 que el ingreso de un medicamento se ejecute


Táctica: cuando se haya comprado.
Una vez se ubique el registro de compra por medio de la
Táctica: función “Búsqueda de compra” descrita anteriormente. Se
presionará el botón “anexar”.
Se revisará la tabla de Registro de inventario de la base
Criterio de éxito: 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 la Verificar que los procesos de cuando haya compras sean


Táctica: exitosos.
Por medio del formulario de pedido y factura de venta se
Táctica:
realizan la verificación de la compra
Se revisará la tabla de compra a proveedores de la base de
datos y se verificará que el registro diligenciado en el
Criterio de éxito: 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.
Por medio del formulario de entrega de medicamentos
ingresar en los campos los datos solicitados y presionar el
Táctica: 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.
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
Criterio de éxito: 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 la Verificar los médicos autorizados a realizar prescripciones a


Táctica: pacientes
Por medio del formulario se registran los médicos
autorizados a realizar prescripciones de medicamentos.
Táctica:
Se enviarán datos incorrectos en los campos para verificar
que los avisos de información inválida sean mostrados.
Se revisará la tabla de registro de médico en la base de
datos y se verificará que el registro diligenciado en el
Criterio de éxito: 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:
Por medio del formulario de registro de médico se podrán
buscar registros de la base de datos.
Táctica:
Si no se encuentran registrados avisara por medio de un
mensaje.
En el formulario de Cargos, se debe cargar la información
del registro completo encontrado.
Criterio de éxito:
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 la Verificar la correcta modificación el registro del médico.


Táctica:
 Por medio del formulario de registro de médicos se
Táctica: podrán Modificar registros de la base de datos.

En el formulario de registro de médicos, se debe cargar


la información del registro completo encontrado.
Criterio de éxito: 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


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

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


Criterio de éxito: 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:
Una vez se ubique el registro inventario de medicamentos
descrita anteriormente Se presionará el botón “copiar”
Táctica: “imprimir”.
Estos reportes se pueden solicitar a el tiempo deseado
Se revisará la tabla de reporte de la base de datos y se
Criterio de éxito: verificará que el registro haya generado correctamente
especificando laboratorio y fecha de vencimiento.
Consideraciones
Ninguna
Especiales:
Reportes de medico

Objetivo de la Verificar que los medicamentos que entreguen los médicos


Táctica: sean los autorizados.
Una vez se ubique el registro de parte del médico descrita
anteriormente, se produzca la información del medicamento
Táctica: autorizado. Se presionará el botón “copiar” “imprimir”.
Estos reportes se pueden pedir en cualquier momento que
sea consultado.
Se revisará la tabla de médicos en la base de datos que el
Criterio de éxito:
registro se haya realizado correctamente.
Consideraciones
Ninguna
Especiales:

También podría gustarte