UNIDAD IV EVALUACION DE PROYECTOS DE SOFTWARE . UNIDAD IV EVALUACION DE PROYECTOS DE SOFTWARE

Evaluación de proyectos ESTRATEGIAS DE PRUEBA DEL SOFTWARE Cualquier estrategia de prueba debe incorporar: 1) planificación de la prueba 2) el diseño de casos de prueba 3) 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.

Y todas quiere decir todas 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 probar Dependerá de los requerimientos 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) Dar de alta una entrada utilizando valores reales. Dar de alta una entrada omitiendo algunos datos obligatorios. Dar de alta al menos 3 entradas seleccionando aleatoriamente diferentes opciones en campos list-box. 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) Para los puntos 1 y 3 se deberá verificar mediante el modulo de edición y de reportes que los datos fueron capturados satisfactoriamente. Para el punto 2 esperamos que todos los datos obligatorios no se almacenen en blanco Para los puntos 2 y 4 esperamos un mensaje de advertencia indicando claramente el error de omisión o duplicidad al usuario. 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/2008 11:00 – 12:00 F1 Secretarias: 1.- Lourdes Ojeda 2.- Blanquita Josué Estrada Dirección de la F.C. 12:30 – 1:00 F2 Director de la F.C. Martha López …

Ejecución del Plan de Prueba (Ejemplo) Clave: F1 Fecha / Hora: 14/11/2008; 11:00 – 12:00 Evaluador: Secretarias: Lourdes Ojeda y Blanquita Ejecutor: 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 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. Las pruebas hechas en durante el desarrollo probablemente no valdrán como pruebas en esta fase.

Ejercicio Realizar el Plan de Pruebas para su proyecto