EJECUCIÓN Y REPORTE DE PRUEBAS FUNCIONALES Y NO … · ejecuciÓn y reporte de pruebas funcionales...

EJECUCIÓN Y REPORTE DE PRUEBAS FUNCIONALES Y NO-FUNCIONALES TÉCNICAS DE PRUEBAS DE SOFTWARE INGENIERÍA DE SISTEMAS UNIVERSIDAD DEL VALLE DOCENTE BEATRIZ FLORIAN GAVIRIA

Basado parcialmente en material de la empresa GreenSQA S.A

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

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 2

GENERALIDADES DE LA FASE DE EJECUCIÓN DE PRUEBAS


Preparación de ambiente §  Definición de ambiente controlado para

pruebas funcionales. (Fichas Técnicas) §  Definición de ambiente para pruebas no-

funcionales (Fichas Técnicas)

Iteraciones Pruebas §  Ejecución de requerimientos de pruebas §  Ejecución de scripts para pruebas §  Registro de hallazgos de NC §  Reproceso de NC §  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

FASE EJECUCIÓN DE PRUEBAS


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.

q  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.

q En cada iteración de pruebas se registran los hallazgos o No Conformidades (NC) de software.


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:

q  Pruebas de Rendimiento q  Pruebas de Seguridad q  Pruebas de Compatibilidad q  Pruebas de Usabilidad.


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.



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



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.



Ingeniero de Pruebas de software •  Seleccionar los requerimientos de pruebas a ejecutar en cada iteración.

•  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.


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.

q Relevancia de las funcionalidades del negocio.

q Estabilidad del componente de software: Para la primera iteración de pruebas implica ejecución de todos los requerimientos.

q 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.

q Lo determinado por el backlog priorizado (metodologías ágiles)



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 (RP) 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)

•  Procesos o funcionalidades a probar (1 fila x RP) q  Identificador del requerimiento de prueba q  Pasos o descripción del requerimiento de

prueba q  Datos de entrada o elemento a probar q  Resultado esperado q  Iteración de la prueba q  Observaciones: Precondiciones, pos-

condiciones, requisitos. q  Versión

GENERALIDAD DEL DISEÑO DE CASOS DE PRUEBAS

Requerimiento de Prueba



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)


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.

q Instancia de Software Independiente: (Aplicación y Base de Datos). El acceso exclusivo para el equipo de pruebas de software.



• Hardware necesario para las pruebas: Procesador, memoria, disco duro, dispositivos de multimedia, impresora, etc.

q 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.


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.


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.




Clasificación (severidad) de No Conformidades •  Bloqueantes

q 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.

q 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 q Se presenta cuando al ejecutar un programa sus resultados no corresponden al

resultado esperado. q 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 q 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.



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.



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.


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



OJO con la 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 e-mail.

Qué tipo de información publico? Email.feedingAlarm.FailText Email.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.”



Mala redacción en el reporte de las no conformidades:

•  No Conformidades Incompletas

q “SIGUE EL ERROR EN EL SCROLL, EL CAMBIO QUE HICIERON NO ERA EL QUE YO MANDE EN EL ARCHIVO...... REVÍSENLO POR FAVOR ”

q “La forma que esta bien es la segunda y al comparar esta información con la primera no concuerdan.”

q “Se registran errores en los resultados”

q “Hay error de carga de pagina.”



Reporte de No Conformidades •  Una de las actividades más 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? Funcionalidad, forma, plantilla, API o unidad de software

Cuándo? Condiciones mediante las cuales se originó la No Conformidad

Hallazgo

Lo que se vio en realidad sin ambigüedad con captura de pantalla

Clasificación

Log generado (si aplica)

Se espera Lo que se esperaba ver. “Se espera que ..”


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



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.



Resumen de ejecución de la Iteración:


Total NC Bloqueantes

Total NC Funcionales

Total NC Presentación

Total NCTotal Reqs Prueba

DiseñadosReqs Prueba Ejecutados

Reqs Prueba con fallos Reqs Prueba OKReqs Pendientes por

ejecutar

0 0 00 0 00 0 00 0 00 0 0

0 0 0 0 0 0 0 0 0

1ra. Iteración


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.


RETROALIMENTACIÓN DEL PROCESO

35 EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA

RETROALIMENTACIÓN DEL PROCESO DE PRUEBAS

Retroalimentación realizada por Iteración y al final del proceso.

•  Informes de Pruebas q Estadísticas q Indicadores

•  Uso de medios para Difusión de Resultados

q Carteleras q Intranet q Mails



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.



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




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)*100


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


PRÁCTICA


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ó en sus tareas o sustentaciones.

Retroalimentación • Haga un análisis de indicadores de ejecución de pruebas

para el ejercicio anterior.


EJECUCIÓN Y REPORTE DE PRUEBAS FUNCIONALES Y NO … · ejecuciÓn y reporte de pruebas funcionales...

Documents

Transcript of EJECUCIÓN Y REPORTE DE PRUEBAS FUNCIONALES Y NO … · ejecuciÓn y reporte de pruebas funcionales...