.

UNIDAD IV

EVALUACION DE PROYECTOS DE

SOFTWARE

Evaluación de proyectosESTRATEGIAS DE PRUEBA DEL

SOFTWARECualquier estrategia de prueba debe incorporar: 1) planificación de la prueba2) el diseño de casos de prueba3) la ejecución de las pruebas, y 4) la agrupación y evaluación de los datos resultantes.todo esto constituye nuestro Plan de Pruebas.

Plan de Pruebas Se trata de probar todas las

funcionalidades de nuestro sistema …. Y todas quiere decir todas

Para esto lo mejor que se puede hacer es ESCRIBIR las pruebas a llevar a cabo en un Plan de Pruebas ….

Por cierto, funcionalidad no es solo aplicaciones.

Temas típicos a probarDependerá de los requerimientosrequerimientos definidos en cada

proyecto, pero existen categorías comunes: Pruebas de funcionalidad (con múltiples usuarios y

REALES y en condiciones de producción … a través de la WAN, etc.,…)

Pruebas de usabilidad (que tan bien puede un usuario usar el producto – interfaces y contenidos)

Pruebas de carga Pruebas de servidores, y conectividad (LAN y WAN) Seguridad, tanto acceso como autorización (sobretodo

si hay acceso a Internet …) Pruebas de respaldo y recuperación

Entregables de las Pruebas:

Plan de Pruebas del sistema. Descripción de las pruebas Diseño de la prueba y resultado esperado Calendario de ejecución

Ejecución del Plan de Prueba Resultado obtenido Tomar acciones para corregir las fallas Aplicar la prueba nuevamente

Ejemplo Plan de Pruebas del sistema.

Categoría: Funcionalidad Clave: F-1 Evaluador: 2 Secretarias Descripción: Evaluar el correcto almacenamiento de

información en cada uno de los módulos de altas (3) de la aplicación.

Diseño: (Para cada uno de los módulos)1. Dar de alta una entrada utilizando valores reales.2. Dar de alta una entrada omitiendo algunos datos obligatorios.3. Dar de alta al menos 3 entradas seleccionando aleatoriamente

diferentes opciones en campos list-box.4. Dar de alta múltiples entradas duplicando claves o nombres

utilizados como índices.

Ejemplo Plan de Pruebas del sistema.

Resultados Esperados: (Para cada uno de los módulos)

1. Para los puntos 1 y 3 se deberá verificar mediante el modulo de edición y de reportes que los datos fueron capturados satisfactoriamente.

2. Para el punto 2 esperamos que todos los datos obligatorios no se almacenen en blanco

3. Para los puntos 2 y 4 esperamos un mensaje de advertencia indicando claramente el error de omisión o duplicidad al usuario.

4. Para los puntos 2 y 4 esperamos que después del mensaje de advertencia todos los datos previamente capturados por el usuario permanezcan.

Ejemplo Plan de Pruebas del

sistema. Plan de Ejecución:

Fecha / Hora Clave Evaluador Ejecutor Lugar

14/11/200811:00 – 12:00

F1 Secretarias: 1.- Lourdes Ojeda2.- Blanquita

Josué Estrada Dirección de la F.C.

14/11/200812:30 – 1:00

F2 Director de la F.C. Martha López Dirección de la F.C.

…

Ejecución del Plan de Prueba (Ejemplo)

Clave: F1 Fecha / Hora: 14/11/2008; 11:00 – 12:00

Evaluador: Secretarias: Lourdes Ojeda y BlanquitaEjecutor: Josué Estrada

Descripción: Evaluar el correcto almacenamiento de información en cada uno de los módulos de altas (3) de la aplicación.

Acciones Resultados Esperados Resultados Obtenidos

[1] Dar de alta una entrada utilizando valores reales.

[2] Dar de alta una entrada omitiendo algunos datos obligatorios.

[3] Dar de alta al menos 3 entradas seleccionando aleatoriamente diferentes opciones en campos list-box.

[4] Dar de alta múltiples entradas duplicando claves o nombres utilizados como índices.

[1] Para los puntos 1 y 3 se deberá verificar mediante el modulo de edición y de reportes que los datos fueron capturados satisfactoriamente.

[2] Para el punto 2 esperamos que todos los datos obligatorios no se almacenen en blanco

[3] Para los puntos 2 y 4 esperamos un mensaje de advertencia indicando claramente el error de omisión o duplicidad al usuario.

[4] Para los puntos 2 y 4 esperamos que después del mensaje de advertencia todos los datos previamente capturados por el usuario permanezcan.

[1]

[2]

[3]

[4]

Tips para ejecutar el Plan de Pruebas:

Se debe prevenir al cliente y usuarios sobre esta fase que va entre el fin del desarrollo y el comienzo de su uso.

En este sentido, hay que anotar que los errores serán de común ocurrencia y no situaciones aisladas.

Hay que llevar un recuento de ellos y hacer un seguimiento ordenado de la forma en que son abordados y corregidos.

Escoger usuarios mas relevantes para el sistema.

Ejecutar las pruebas en un entorno real de operación.

Conclusiones

Las pruebas hechas en durante el desarrollo probablemente no valdrán como pruebas en esta fase.

Lo que no se pruebe ahora está garantizado que va a fallar (ley de murphy)

La única forma de hacer pruebas y garantizar que se ha probado todo lo necesario es sentándose a escribirlas en un plan de pruebas. De lo contrario será un desastre.

Ejercicio Realizar el Plan de Pruebas para su

proyecto