ANÁLISIS Y DISEÑO DE SISTEMA II

Tema: Pruebas

Introducción

En la realización de estas pruebas es importante comprobar la cobertura de los

requisitos, dado que su incumplimiento puede comprometer la aceptación del
sistema por el equipo de operación responsable de realizar las pruebas de
implantación del sistema, que se llevarán a cabo en el proceso Implantación y
Aceptación del Sistema.
El objetivo de las pruebas del sistema es comprobar la integración del sistema de
información globalmente, verificando el funcionamiento correcto de las interfaces
entre los distintos subsistemas que lo componen y con el resto de sistemas de
información con los que se comunica.

Pruebas basadas en la no ejecución

Inspecciones
Pruebas basadas en la ejecución
Casos de prueba de cajas negra
Casos de prueba de caja de vidrio
Que pruebas basadas en la ejecución se deben evaluar
 Utilidad
 Fiabilidad
 Solidez
 Desempeño
 Corrección
Quien debe realizar las pruebas en la no ejecución

Cuando tener pruebas

Después que un sistema de información se ha mantenido de manera satisfactoria

durante muchos años, con el tiempo puede perder su utilidad y ser remplazado por
otro totalmente diferente, así como un caballo que es remplazado fue remplazado
por un automóvil. Así finalmente el sistema de información es destituido y retirado
del servicio. Solo en este punto, cuando se le ha descartado de manera irrevocable,
es tiempo de detener las pruebas.
Para un pensamiento final sorprendente sobre las pruebas
Pruebas basadas en la no ejecución

La mayoría de las personas han tenido la experiencia de preparar un documento

importante y revisarlo una y otras veces hasta estar absolutamente seguras de que
no hay errores de ningún tipo. Sim embargo, cuando se le da el documento a alguien
más para que lo revise, él o ella de inmediato encuentra un error que pasó
inadvertido. Por esta razón no es buena idea para la persona encargada de redactar
un documento ser la única responsable de revisarlo. Todos tenemos puntos ciegos
que permitan que tengan fallas en un documento, y esos mismos puntos ciegos
impiden detectarla en la revisión.
Principios de inspección

La persona que dirige la inspección guía a los otros miembros del equipo a través
de los artefactos para descubrir cualquier falla. No es tarea del equipo descubrir las
fallas, sino simplemente regístrala para corregirlas después. Hay cuatro razones
para hacerlo:
1. Una corrección producida por un comité dentro de las restricciones de tiempo
de la inspección es probable que sea inferior en calidad a una producida por
un individuo capacitado en las técnicas necesarias.
2. Una corrección producida por un equipo de inspección de, por decir algo,
cinco individuos se llevarán cuando menos la misma calidad de tiempo que
una llevada a cabo por una persona y, por consiguiente, cuesta cinco veces
más cuando se considera los salarios del participante.
3. No todos que se etiqueten como fallas en realidad lo son: según la máxima
“si no se rompe, no lo repares”, es mejor que las posibles fallas se examinen
con detenimiento y luego se corrijan solo si realmente ocurra un problema,
en vez de hacer que el equipo intente “reparar” algo que esta completamente
bien.
4. Simplemente no hay tiempo suficiente en una inspección para detectar y
corregir las fallas. Ninguna inspección debe durar más de dos horas. El
tiempo debe invertirse en la detección y el registro de fallas, no en la
corrección de la misma.
Pruebas basadas en la ejecución

Una prueba basada en la ejecución, revisión y retroalimentación de las

funcionalidades previamente diseñadas para el software. Las pruebas funcionales
se hacen mediante el diseño de modelos de prueba que buscan evaluar cada una
de las opciones con las que cuenta el paquete informático. Dicho de otro modo, son
pruebas específicas, concretas y exhaustivas para probar y validar que el software
hace lo que debe y sobre todo, lo que se ha especificado.
Análisis de requisitos (Planificación)
En esta fase se inicia la elaboración del modelo jerárquico de requisitos de prueba
partiendo de los procesos funcionales que soporta el producto o activo de software
a evaluar. A partir de las funcionalidades se elaborará el plan de pruebas. Hay que
obtener toda la información posible de las aplicaciones sobre las cuales se
realizarán las pruebas. Esta información se deberá conseguir de toda la
documentación disponible sobre su funcionamiento y hablando con el personal
responsable de la misma.
Diseño del plan de pruebas (Preparación)
En esta fase se identifica, acuerda y especifican los atributos y características de
calidad que se van a probar. El objetivo es diseñar las pruebas para que tengan la
mayor probabilidad de encontrar defectos con la mínima cantidad de esfuerzo y
tiempo. Serán pruebas que se llevarán a cabo a través de la interfaz gráfica del
software (GUI). Es decir, demostrar que las funciones del software son operativas,
que la entrada se acepta de forma adecuada y que se produce una salida correcta,
así como que la integridad de la información externa se mantiene. Se crearán casos
de prueba divididos en pasos (steps) para cada acción a realizar con un resultado
esperado asociado, que podrá ser verificado. Durante la fase de diseño también se
especifican los datos de entrada necesarios para que los casos de pruebas
definidos puedan ser ejecutados (ya sea buscando el éxito de la prueba, o bien el
fallo).
Ejecución
En esta fase se ejecutarán los casos de prueba anteriormente diseñados de forma
manual. Hay que seguir al detalle el guion establecido dejando cierta libertad al
testar para detectar situaciones anómalas no contempladas. Las baterías de
pruebas serán ejecutadas como mínimo una vez antes del paso a producción,
independientemente de las ejecuciones anteriores. Los casos de prueba fallados se
reportarán a los desarrolladores para su corrección hasta que su resultado sea
correcto.
Gestión de Incidencias (Defectos)
La gestión de incidencias es una parte implícita de la fase de ejecución, pero que al
tener una alta importancia en las pruebas funcionales, diferenciamos como una
etapa independiente. Cuando al realizar la acción de un step el resultado obtenido
no es el esperado, habrá que abrir o reportar una incidencia para que el equipo de
desarrollo tenga constancia del error. La gestión de incidencias es el principal canal
de comunicación con el equipo de desarrollo. Las incidencias han de ser claras y
con todo lujo de detalle, tienen que describir el error para que el equipo de desarrollo
pueda comprenderlo perfectamente, reproducirlo, localizarlo y poder solucionarlo.
Se deberá mantener una continua comunicación con el equipo de desarrollo para
conocer el estado de los defectos y poder realizar las repruebas necesarias para su
cierre.
Manuales
Las pruebas funcionales manuales son las que ejecuta un testar como si fuese un
usuario, pero siguiendo una serie de pasos establecidos o test plan, diseñado en el
análisis de los requisitos para garantizar que hace lo que debe (casos positivos),
que no falla (casos negativos) y que es lo que se ha solicitado. El testar realizará
las acciones indicadas en cada step del caso de prueba comprobando que se
cumple el resultado esperado. Si el resultado es distinto al esperado, se reportará
un defecto con todo detalle: descripción, datos utilizados, capturas de pantalla, etc.
para facilitar la solución del defecto por parte de los desarrolladores.