Taller 3

Para asegurar un excelente desempeño en el estudio de caso, se solicita antes de su

presentación estudiar el material Objeto de Aprendizaje (OA) titulado Pruebas de software,
que debe leer y asimilar para lograr la conceptualización técnica del presente tema de
estudio.
Para el desarrollo de la evidencia de conocimiento analice el siguiente caso:
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.

Desarrollo
1. Evidencie el modelo, según el ciclo de vida escogido.
El modelo de software seleccionado para orientar el diseño y la construcción del ciclo de
vida requerido para el sistema de la clínica será el denominado “modelo de cascada”, al ser
un modelo que ordena rigurosamente las etapas del ciclo de vida del software de forma tal
que el inicio de cada etapa depende de la finalización de la inmediatamente anterior, lo que
permite la detección de errores de diseño en cada etapa, para aplicar así los rediseños
correspondientes.
 2. Determine alcance de la prueba.
El alcance de pruebas para este proyecto radica en detectar los posibles errores cometidos
en las etapas anteriores del proyecto, para ser corregidos eventualmente, aplicando
diferentes pruebas, herramientas y metodologías en cada una de las etapas.

3. Relacione los tipos de prueba a aplicar.

Con motivo de detectar posibles errores cometidos en la realización de este proyecto se
aplicarán las siguientes pruebas:

 Pruebas de unidad: sirven para comprobar el funcionamiento individual de cada

módulo; se busca asegurar el funcionamiento del código de acuerdo con las
especificaciones, así como la comprobación la lógica del procesamiento interno.

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

 Pruebas de integración descendente: sirve para comprobar que el conjunto de los

módulos de un sistema funciona adecuadamente; se aplica de tal manera que los
módulos de integran jerárquicamente hacia abajo, iniciando con el módulo
principal.

 Prueba de aceptación: sirve para confirmar que el producto está listo para el uso
operativo; es desarrollada antes de que el proyecto se instale dentro de un ambiente
de producción. Esta prueba es realizada por parte del cliente o de un especialista de
la aplicación.

 Prueba alfa: sirve para ser aplicada una vez finalice el proyecto con el fin de ejecutar
el sistema en ambientes simulados para encontrar errores, al realizar esta prueba al
final, es usada para pulir aspectos de la interfaz de usuario del sistema.

4. Analice estrategias de pruebas.

El plan de pruebas se basará en pruebas unitarias, funcionales, instalación y regresión
teniendo en cuenta los requerimientos no funcionales.
 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.

5. Exponga criterios de salida y los aspectos anexos que considere necesario tener
en cuenta.

 Criterios de salida del plan de pruebas:

- Obtener éxito en el set de pruebas diseñadas para cada módulo.
- Obtener pleno cumplimiento de los criterios de aceptación definidos
por el cliente.
- Aplicación de correcciones en funcionamiento.
- Perfecto funcionamiento de la aplicación por fase terminada.