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.