Está en la página 1de 20

1

EVIDENCIA: ESTUDIO DE CASO PRUEBAS DE SOFTWARE

Presentado por:

LEYDI YOHANA SUA NIÑO

Tutor:

EVARISTO MINA ARROYO

Ficha: 2017771 – APLICACIÓN DE LA CALIDAD EN EL DESARROLLO DE


SOFTWARE

SERVICIO NACIONAL DE APRENDIZAJE SENA

Duitama Boyacá Octubre unidad 2

2
EVIDENCIA: CARACTERISTICAS DE LOS MODELOS DE LA CALIDAD DEL
SOFTWARE

Presentado por:

LEYDI YOHANA SUA NIÑO

TRABAJO DE CALIDAD EN EL DESARROLLO DE SOFTWARE

Tutor:

EVARISTO MINA ARROYO

INGENIERO DE SISTEMAS

Ficha: 2017771 – CALIDAD EN EL DESARROLLO DE SOFTWARE

SERVICIO NACIONAL DE APRENDIZAJE SENA

Duitama Boyacá Octubre unidad 2

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

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

5
OBJETIVO GENERAL

Analizar y aplicar los conceptos básicos dados en el proceso de pruebas y


construcción del software.

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

7
DESARROLLO

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.

8
3. Relacione los tipos de prueba a aplicar.

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

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.

9
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 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 Conformidad Técnica: Pruebas de


Prueba: operación

10
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 Facilidad de Uso Técnica: Revisiones


Prueba:
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: Coordinador Proceso:
Diseño Código - Revisión pasó a paso pseudo
código.

Factor de Facilidad de Pruebas de


Técnica:
Prueba: Operación 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

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

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

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.

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

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

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

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

16
 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.
Consideraciones Ninguna
Especiales:

 Medicamentos formulados por médicos

Registro de médicos

Objetivo de la Verificar los médicos autorizados a realizar


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

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

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.

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

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

20

También podría gustarte