CLASE # 9 EJECUCIÓN DE PRUEBAS

Transcripción

1 CLASE # 9 EJECUCIÓN DE PRUEBAS M - TÉCNICAS DE PRUEBAS DE SOFTWARE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN UNIVERSIDAD DEL VALLE SEMESTRE 2013A - DOCENTE BEATRIZ FLORIAN GAVIRIA Basado parcialmente en material de la empresa GreenSQA S.A

2 AGENDA Generalidades de la fase de ejecución de pruebas Definición de iteración Preparación del ambiente de pruebas Ejecución de pruebas por iteraciones Reporte de hallazgos Retroalimentación Actividad práctica 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 2

3 GENERALIDADES DE LA FASE DE EJECUCIÓN DE PRUEBAS 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 3

4 FASE EJECUCIÓN DE PRUEBAS Preparación de ambiente Definición de ambiente controlado para pruebas funcionales. Definición de ambiente para pruebas nofuncionales Iteraciones Pruebas Ejecución de requerimientos de pruebas Registro de hallazgos de NC Reproceso de NC Ejecución de scripts para pruebas Análisis de resultados de pruebas Seguimiento / Control / Retroalimentación Calculo de indicadores de producto Informe avance proceso pruebas Informe cierre pruebas funcionales Informe cierre pruebas no-funcionales 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 4

5 PROPÓSITO Ejecución de pruebas mediante la definición de las actividades requeridas para ejecutar los requerimientos de pruebas identificados en la fase de diseño de pruebas. La fase de ejecución de pruebas se realiza por iteraciones de pruebas. (Total o un subconjunto de los requerimientos de pruebas). Reportar los hallazgos y asegurar su corrección por parte del equipo de desarrollo de software. En cada iteración de pruebas se registran los hallazgos o No Conformidades (NC) de software EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 5

6 ALCANCE Nuevos productos Mantenimiento: Actualización de funcionalidades a productos Pruebas funcionales: Aplica para los diferentes tipos de pruebas dinámicas de software. Pruebas no-funcionales: Pruebas de Rendimiento Pruebas de Seguridad Pruebas de Compatibilidad Pruebas de Usabilidad EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 6

7 RESPONSABILIDADES EN EJECUCIÓN Cliente de pruebas Brindar un ambiente de pruebas controlado Gestionar las mejoras de procesos identificadas por el equipo de pruebas Apoyar el cumplimiento de los acuerdos de nivel de servicio previamente establecido Apoyar la gestión de datos de producción para la ejecución de pruebas EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 7

8 RESPONSABILIDADES EN EJECUCIÓN Gerente de pruebas de software Comunicar a los gerentes de proyecto los cambios metodológicos vigentes en el proceso de pruebas Gestionar los recursos necesarios para la ejecución de pruebas Definir y hacer cumplir los acuerdos de nivel de servicio Realizar seguimiento y control al plan de proyecto 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 8

9 RESPONSABILIDADES EN EJECUCIÓN Líder de pruebas de software Velar por un ambiente de pruebas controlado. La gestión de las actividades definidas en los procedimientos de ejecución de pruebas. Presentación a la gerencia de pruebas de informes parciales, que permiten verificar el seguimiento del proceso. Analizar información de causa de no conformidades y realizar informes EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 9

10 RESPONSABILIDADES EN EJECUCIÓN Ingeniero de Pruebas de software Seleccionar los requerimientos de pruebas a ejecutar Registrar las no conformidades identificadas Ejecutar las actividades de pruebas definidas en el plan de pruebas Reportar los hallazgos en las herramientas definidas. Calcular los indicadores de pruebas por funcionalidad. Identificar acciones de mejora que minimicen la aparición de NC Almacenar la información de acuerdo al plan de almacenamiento definido en el plan de pruebas. Retroalimentar al líder de pruebas sobre el avance en la ejecución de pruebas EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 10

11 DEFINICIÓN DE ITERACIÓN 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 11

12 DEFINICIÓN DE ITERACIÓN Selección de Requerimientos a Ejecutar Estrategia de ejecución definida en el plan: De acuerdo al alcance y secuencia de entregas definida en el cronograma de desarrollo de software. Relevancia de las funcionalidades del negocio. Estabilidad del componente de software: Para la primera iteración de pruebas implica ejecución de todos los requerimientos. Para iteraciones posteriores, se selecciona un subconjunto de requerimientos de pruebas de acuerdo a la estabilidad funcional determinada por la medición de los indicadores de calidad EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 12

13 DEFINICIÓN DE ITERACIÓN Selección de Requerimientos a Ejecutar Tipo de prueba a ejecutar: De acuerdo al tipo de pruebas a ejecutar, se seleccionan los requerimientos de pruebas registrados en el Matriz de Requerimientos de Prueba (MRP) Requerimiento de prueba Una condición o aspecto particular que requiere ser verificado o probado sobre una unidad o conjunto de unidades de software desarrolladas o modificadas, para garantizar que éstas se incorporan al producto con calidad y cumplen con las especificaciones pactadas con el usuario o el alcance definido para dicha funcionalidad Matriz de Requerimientos de Prueba (MRP) Proceso o funcionalidad a probar Identificador del requerimiento de prueba Pasos o descripción del requerimiento de prueba Datos de entrada o elemento a probar Resultado esperado Iteración de la prueba Observaciones: Precondiciones, pos-condiciones, requisitos. Versión 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 13

14 GENERALIDAD DEL DISEÑO DE CASOS DE PRUEBAS Requerimiento de Prueba 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 14

15 DEFINICIÓN DE ITERACIÓN 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 15

16 DEFINICIÓN DE ITERACIÓN Selección de Requerimientos a Ejecutar Para productos en mantenimiento: Requerimientos diseñados para probar la funcionalidad que se actualiza + el impacto funcional sobre otras funcionalidades. Es necesario programar un conjunto de pruebas de sistema de los procesos posiblemente impactados. (Pruebas de regresión sobre el SW) 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 16

17 PREPARACIÓN DE AMBIENTE DE PRUEBAS 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 17

18 PREPARACIÓN DE AMBIENTE DE PRUEBAS Utilizando la ficha técnica (FT) de producto: Especificación de la configuración de máquinas (clientes y servidores) en que se ejecutarán las pruebas; el sistema operativo, browser y configuración TCP/IP. Especificación del software de sistema y de apoyo a la prueba, motor de base de datos, maquinas virtuales, servidor web, simuladores. Instancia de Software Independiente: (Aplicación y Base de Datos). El acceso exclusivo para el equipo de pruebas de software EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 18

19 PREPARACIÓN DE AMBIENTE DE PRUEBAS Hardware necesario para las pruebas: Procesador, memoria, disco duro, dispositivos de multimedia, impresora, etc. Especificación de recursos especiales requeridos: Dispositivos móviles, lectores de barras, PDA s, monitores touch. Sistema de gestión de configuración: práctica estándar de gestión de configuración, que permita mantener controlado el ambiente de pruebas y el paso de los objetos probados al ambiente de producción EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 19

20 GENERACIÓN DE DATOS DE PRUEBAS Datos de Pruebas: Datos de producción. Datos generados. Datos capturados. Datos creados manualmente. Datos aleatorios (útiles en pruebas de estrés y carga) Cuando la aplicación es completamente nueva, se ejecutan las pruebas en la secuencia necesaria para hacer manualmente la carga inicial de datos, en caso contrario, se tratará de reutilizar datos de un cliente en operación, es decir datos de producción EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 20

21 EJECUCIÓN DE PRUEBAS 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 21

22 EJECUCIÓN DE PRUEBAS Ejecutar en el software los requerimientos de pruebas seleccionados HH (costo) invertido en la ejecución y la cantidad de hallazgos EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 22

23 EJECUCIÓN DE PRUEBAS Clasificación (severidad) de No Conformidades Bloqueantes Es el tipo de no conformidad que detiene la operación de un programa / componente o hace que este arroje resultados que impiden la continuidad de la operación del cliente. Ejemplos de este tipo son: Al ejecutar un proceso se muestra un mensaje de error que indica que no puede continuar. Al ejecutar el programa se cierra la sesión. Al ejecutar el programa se bloquea la aplicación. Funcionales Se presenta cuando al ejecutar un programa sus resultados no corresponden al resultado esperado. Ejemplos de este tipo son: No realiza validaciones necesarias, o ejecuta validaciones innecesarias. El total de un reporte no corresponde a la suma de los valores relacionados. Presentación Son no conformidades relacionadas con la presentación del programa, estos deben ajustarse a los estándares definidos y con las reglas gramaticales y ortográficas del idioma en que es presentado el programa EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 23

24 EJECUCIÓN DE PRUEBAS El resultado real de ejecución debe cumplir con dos características fundamentales que permiten evidenciar su cumplimiento: La correctitud: exactitud de los resultados reales vs los esperados. La completitud: cobertura de los resultados reales vs los esperados EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 24

25 EJECUCIÓN DE PRUEBAS Criterio de Cierre de Iteración de Pruebas El criterio de cierre de una iteración, corresponde a la ejecución todos aquellos requerimientos de prueba planeados y que no se afectan por la identificación de No conformidades funcionales o incumplimientos en la entrega de los grupos de desarrollo EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 25

26 REPORTE DE HALLAZGOS 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 26

27 REPORTE DE HALLAZGOS Análisis Analizar los resultados obtenidos en la prueba versus los resultados esperados, con base en lo cual determinaran la presencia de no conformidades. Tener en cuenta previamente: Los datos de prueba, La ejecución de los pasos de la prueba El ambiente de pruebas La definición del requerimiento de prueba 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 27

28 REPORTE DE HALLAZGOS Mala redacción en el reporte de las no conformidades: No Conformidades Agresivas No es lógico crear un grupo vacío, se debe colocar una validación de algunos campos requeridos en la creación No se encuentra aún el sentido para el perfil dependencia, actualmente sólo puede entrar, cerrar sesión y cambiar el perfil a otro. El calendario como actuaría en este perfil? No Conformidades Preguntas Hola PEPITO este tipo de etiquetas aparecen en el diccionario sobre . Qué tipo de información publico? .feedingAlarm.FailText .StateAlarm.Yellow Y muchas más... Qué texto pongo? Como agregarle la función y/o icono del calendario a un campo de la forma EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 28

29 REPORTE DE HALLAZGOS Mala redacción en el reporte de las no conformidades: No Conformidades Incompletas SIGUE EL ERROR EN EL SCROLL, EL CAMBIO QUE HICIERON NO ERA EL QUE YO MANDE EN EL ARCHIVO... REVÍSENLO POR FAVOR La forma que esta bien es la segunda y al comparar esta información con la primera no concuerdan. Se registran errores en los resultados Hay error de carga de pagina EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 29

30 REPORTE DE HALLAZGOS Reporte de No Conformidades Una de las actividades mas importantes y comunes que hace un Ingeniero de Pruebas es reportar no conformidades y la forma como se reporta afecta directamente la forma en que ésta será corregida por el Desarrollador. La estructura para la redacción de las No Conformidades debe considerar de manera explícita los siguientes elementos: No conformidad Dónde? Cuándo? Hallazgo Funcionalidad, forma, plantilla, API o unidad de software Condiciones mediante las cuales se originó la No Conformidad Lo que se vio en realidad sin ambigüedad con captura de pantalla Clasificación Se espera Log generado (si aplica) Lo que se esperaba ver. Se espera que EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 30

31 REPORTE DE HALLAZGOS Ejemplo - Reporte de No Conformidades GENERAL/ADMON DE USUARIOS/USUARIO: Cuando se está almacenando un usuario y el sistema encuentra que faltan datos muestra el mensaje: "Se encontraron caracteres no válidos" y borra los datos que se ingresaron en clave, confirmar clave y activo/inactivo. Se espera que el sistema muestre los datos ingresados hasta que se complete la operación exitosamente. DONDE: GENERAL/ADMON DE USUARIOS/USUARIO CUANDO: Al almacenar un usuario y el sistema encuentra que faltan datos muestra el mensaje: "Se encontraron caracteres no válidos" HALLAZGOS: El sistema borra los datos que se ingresaron en los campos clave y confirmar clave. SE ESPERA: Que el sistema muestre los datos que se ingresaron hasta que se complete la operación exitosamente 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 31

32 REPORTE DE HALLAZGOS Registro de Ejecución de Requerimientos de Pruebas Ok, si el requerimiento se ejecuto de manera normal. NoK, si se generó una no conformidad. PTE ENT, si el requerimiento no se pudo ejecutar debido a la entrega incompleta del release. PTE_NC, si el requerimiento no se pudo ejecutar por la identificación de NC previas. N/A, en caso que el requerimiento ya no aplique para la funcionalidad a probar EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 32

33 REPORTE DE HALLAZGOS Resumen de ejecución de la Iteración: 1ra. Iteración Total NC Bloqueantes Total NC Funcionales Total NC Presentación Total NC Total Reqs Prueba Diseñados Reqs Prueba Ejecutados Reqs Prueba con fallos Reqs Prueba OK Reqs Pendientes por ejecutar EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 33

34 REPORTE DE HALLAZGOS Causales en las No Conformidades Análisis: Se evidencia problemas de completitud y alcance funcional de un requerimiento. Diseño: Relacionada con el modelo de BD, interfaz gráfica, arquitectura del producto. Desarrollo: Causados por la codificación del producto. Gestión Configuración: actualizaciones del ambiente de pruebas o con los objetos empaquetados en el instalador del producto. Documentación: Coherencia en documentación técnica y funcional del producto EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 34

35 RETROALIMENTACIÓN DEL PROCESO 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 35

36 RETROALIMENTACIÓN DEL PROCESO DE PRUEBAS Retroalimentación realizada por Iteración y al final del proceso. Informes de Pruebas Estadísticas Indicadores Uso de medios para Difusión de Resultados Carteleras Intranet Mails 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 36

37 RETROALIMENTACIÓN DEL PROCESO DE PRUEBAS Información de No Conformidades: Informe estadístico de clasificación de las no conformidades: Severidad, Componente Funcional, Causa, Estado. Información del Proceso de Pruebas: Informe que permita resaltar o identificar oportunidades de mejora sobre el proceso de pruebas: uso de herramientas, desviaciones de tiempos, reutilización de diseño de pruebas, uso de técnicas de diseño de pruebas. Información de Mejora de Procesos: A partir del análisis de las causas de las no conformidades, se identifican las acciones de mejora necesarias para evitar futuras no conformidades por la misma causa EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 37

38 RETROALIMENTACIÓN DEL PROCESO DE PRUEBAS Indicadores de Producto Correctitud: Permite identificar que porcentaje de las funcionalidades evaluadas se comportan correctamente de acuerdo al resultado esperado A: Funcionalidades con no conformidades en la evaluación B: Total de funcionalidades evaluadas Correctitud = 1-A/B Completitud en desarrollo: Permite identificar el porcentaje de funcionalidades implementadas por el grupo de desarrollo y listas para ser validadas por el grupo de aseguramiento de calidad. A: Funcionalidades faltantes por desarrollar B: Total de funcionalidades descritas en MDF Completitud en desarrollo= 1- A/B 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 38

39 RETROALIMENTACIÓN DEL PROCESO DE PRUEBAS Indicadores de Producto Densidad de NC: Permite identificar la razón de no conformidades identificadas por requerimiento ejecutado en la actividad de pruebas. A: No conformidades B: Requerimientos ejecutados Densidad NC = A/B *Nota: Se deben excluir las NC anuladas. Confiabilidad: Permite identificar el porcentaje de confiabilidad del producto basado en la densidad de NC encontrada en cada iteración de pruebas. Confiabilidad= (1 - Densidad NC)* EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 39

40 RETROALIMENTACIÓN DEL PROCESO DE PRUEBAS Indicadores de Producto 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 40

41 RETROALIMENTACIÓN DEL PROCESO DE PRUEBAS Indicadores de Proyecto Desviación de tiempo de planeación Desviación de esfuerzo en planeación Avance total del proceso Eficiencia en el diseño de pruebas Reproceso Eficacia en las pruebas Impacto en detección de No Conformidades 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 41

42 PRÁCTICA 2013 EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 42

43 PRÁCTICA Reporte de hallazgos Haga la simulación de un reporte de posibles hallazgos de no conformidades utilizando los diseños de pruebas que entregó hoy en su tarea. Retroalimentación Haga un análisis de indicadores de ejecución de pruebas para el ejercicio anterior EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 43