presentacion proceso de testing funcional independiente

8/18/2019 Presentacion Proceso de Testing Funcional Independiente

1/45

PEDECIBA informática Instituto de Computación (InCo)

Facultad de Ingeniería Universidad de la República.

Montevideo, Uruguay

Proceso de Testing FuncionalIndependienteTesis de Maestría en Informática

Beatriz Pérez Lamancha

Setiembre 2006


2/45

Tesis de Maestría en Informática 2

Temario Centro de Ensayos de Software

Contribuciones Proceso de Testing Funcional

• Principales características

• Roles• Etapas

Caso de Estudio

Ajustes realizados Conclusiones

Trabajo a Futuro


3/45


Centro de Ensayos de Software Financiado por la Unión Europea, parte del proyecto proyecto

“Desarrollo tecnológico en sectores clave de la economía uruguaya”

Laboratorios

• Testing Funcional

• Ensayos de Plataformas

Servicios

• Prueba independiente de productos de software

• Consultoría

Mejora de los procesos de prueba

Colaborar en la creación y consolidación del àrea de prueba

• Capacitación Motivación

• Definición de procesos y procedimientos


4/45


Contribuciones Estudio del estado del arte sobre

• Pruebas de software• Proceso de pruebas de software

ProTest

• Definición proceso para pruebas funcionalesindependientes

• Validación y ajuste mediante caso de estudio

• Usado en el Laboratorio de Testing Funcional del CES DeVeloPro

• Herramienta para la documentación y administración deprocesos


5/45


Definiciones* Testing

• Verificación dinámica del comportamiento de unprograma usando un conjunto finito de casos de prueba,seleccionados desde el dominio infinito de ejecución,contra el comportamiento esperado.

• La verificación dinámica implica que para realizar laspruebas siempre hay que ejecutar el programa para losdatos de entrada

Testing Funcional• Validar si el comportamiento observado del

software probado cumple o no con sus especificaciones.

* SWEBOK - IEEE's Software Engineering Body of Knowledge


6/45


Proceso de Testing Funcional Principales características

• Independiente del proceso de desarrollo• Testing funcional de productos

Desde su comienzo

En etapas avanzadas de desarrolloMantenimiento

• Testing basado en los riesgos del producto

• Guiado por los Ciclos de Prueba• Pruebas a partir de los Requerimientos

Adaptado a cada proyecto de prueba


7/45


Testing basado en los riesgos del

producto No es posible probar todo

• ¿qué probar? Identificar junto al cliente las funcionalidades que:

• presenten mayor riesgo para el negocio en caso de no funcionarcorrectamente

Identificar junto a los desarrolladores lasfuncionalidades que:• es mas probable que tengan defectos.

• son mas complejas de desarrollar

Priorizar las funcionalidades que serán verificadas

Identificar las funcionalidades que no serán verificadas

y el riesgo asociado


8/45


Guiado por los Ciclos de Prueba Cada ciclo de prueba está asociado a una

versión ejecutable del producto a probar Cada nuevo ciclo de prueba implica una nueva

versión de uno o más componentes del sistema

En un ciclo de prueba se puede ejecutar una,alguna o todas las pruebas planificadas para elproducto.


9/45


Pruebas basadas en los

Requerimientos Decidir si la salida observada al ejecutar el programa

es la salida esperada. Los requerimientos son analizados y catalogados en el

Inventario de Pruebas

Si no es posible realizar el diseño de las pruebas apartir de los requerimientos

• se trabaja junto con desarrolladores y cliente en mejorarlos requerimientos existentes

• Se explora versiones anteriores del producto

Estudio incremental de los requerimientos en cadaciclo


10/45


Etapas del Proceso de Testing


11/45


Roles Equipo de testing:

• Líder del Proyecto de TestingDirige el proyecto de testing.

• Diseñador

Diseña los casos de prueba

• Tester

Ejecuta los casos de prueba y reporta los resultados

Cliente• Quien desarrolla el producto

• Quien compra el producto

Desarrollador (Contraparte técnica)


12/45


Estudio Preliminar Objetivo: Definir alcance y cronograma para las

pruebas Cliente, Líder de Proyecto

Actividades y Entregables


13/45


Estudio Preliminar

Salidas:• Propuesta de Servicio

Alcance de las Pruebas

Agenda

Cotización

Acuerdo deConfidencialidad


14/45


Planificación

Objetivo: Planificar el proyecto de prueba


15/45


Planificación


16/45


Planificación



17/45


P8 - Definición del Proceso deIncidentes Un incidente puede ser:

• un defecto del producto• una mejora a realizar

• o una observación

El sistema de seguimiento de incidentespermite al equipo de testing:• reportar

• administrar• analizar los incidentes reportados

• y la tendencia de los mismos en cada ciclo de prueba


18/45


Ciclos de Prueba

Objetivo: Generar y ejecutar las pruebas

planificadas para el ciclo


19/45


Seguimiento del Ciclo

Objetivo: Planificación, seguimiento ycontrol del ciclo

Cliente, Líder de Proyecto



20/45


Seguimiento del Ciclo


21/45


Configuración del Entorno

Objetivo: Configurar el ambiente de pruebas,separando los ambientes de desarrollo y testing


Entorno de trabajo

• en el cliente• en el laboratorio del CES

• en laboratorios asociados


22/45


Diseño de las Pruebas

Objetivo: Diseñar los casos de prueba a partirde la especificación del producto

Cliente, Desarrollador, Diseñadores



23/45


Diseño de las Pruebas


24/45


D1 - Diseño de los casos deprueba

Técnicas de Caja Negra Incluye:

• Diseñar las pruebas

• Identificar los datos de prueba

• Matriz de trazabilidad

Conocer qué casos de prueba cubren qué elementosde prueba


25/45


Ejecución de las Pruebas

Objetivo: Contrastar el comportamiento esperadodel producto con su comportamiento real

Tester, Cliente, Desarrolladores Actividades y Entregables


26/45


Ejecución de las Pruebas


27/45


Evaluación Objetivo: Evaluar y archivar el proyecto de

prueba Actividades y Entregables


28/45


Evaluación


29/45


Caso de Estudio Aplicación de Gestión

• Lleva varios años en producción

• Existían dos versiones de la aplicación en clientes distintos• Unificación en una sola versión

Cliente es el gerente de desarrollo

Documentación

• Manual de usuario sin actualizar

Estudio Preliminar

• 3 reuniones con el cliente


30/45


Etapa: Planificación Plan de Pruebas

Alcance para los Ciclos

Proceso de Incidentes

• Bugzilla


31/45


Etapa: Ciclo de Prueba 1 S1 – Planificación del

Ciclo


32/45


Etapa: Ciclo de Prueba 1 Principales desviaciones

• P2 – Revisión de Requerimientos, D1-Diseño

de las pruebas y D2 – Validación de losCasos de Prueba llevaron dos semanas más

• E2 – Ejecución de las Pruebas, E3-TestingExploratorio y E4-Reporte de Incidentes

llevaron una semana más de lo planificado


33/45


Etapa: Ciclo de Prueba 2 Atraso en la nueva versión

• 2 semanas para comenzar el Diseño• 5 semanas para comenzar la Ejecución

La nueva versión unifica dos versiones existentes de

la aplicación S1 – Planificación del Ciclo

• Pruebas de regresión: Ejecutar 42 casos de prueba


34/45


Etapa: Ciclo de Prueba 2


35/45


Etapa: Evaluación Encuesta de satisfacción del cliente

Evaluación del Proyecto e Informe FinalFuncionalidades , Casos e Incidentes

188 8

34

106

5742

205

3825

16

79

Ciclo 1 Ciclo 2 Regresión Total

Cant. Funcionalidades Cant. Casos de Prueba Cant. Incidentes

Cantidad Incidentes por Tipo

107

3

20

7

12 13

20

1 0

21

1

5

0

6

32

Ciclo 1 Ciclo 2 Regresión Total

Funcional - Implementación Incorrecta

Interfaz de UsuarioMensajes erróneos y Falta de Mensaje.Validación faltante o incorrecta


36/45


Etapa : EvaluaciónCantidad Incidentes por Criticidad

3 3 224

0

33

18

14

Ciclo 1 Ciclo 2 Regresión

Alta Media Baja

Ciclo 2

12%

16%

72%

Ciclo 2

12%

16%

72%

Ciclo 2 - Regr es ión

13%

0%

87%

Alta

Media

Baja


37/45


Conclusiones ProTest permitió realizar un proyecto de prueba

que resultó de valor para quién contrató elservicio

• Las características del proceso resultaron unaguía útil

Aspectos positivos de comunicación

• Colaboración del cliente para priorizar y validar

• Plan de Pruebas• Informes de Avance

• Sistema de seguimiento de incidentes web


38/45


Ajustes Realizados Planificación

• Mejora en las mediciones para mejorar lasestimaciones

Se agregan elementos PSP

Mejoras en la forma en como se reporta el esfuerzoTiempo de ejecución de las pruebas para mejorar

planificación de pruebas de regresión

Mejoras en las mediciones realizadas

Cambios en nombre de actividades y momento

en que se realizaban


39/45


Mediciones usadas

D t ió Ad i i t ió d


40/45


Documentación y Administración de

ProTest La documentación del Proceso debe estar:

• Disponible a todos los miembros de la organización

• En un formato imprimible

Herramienta DeVeloPro

• Se definieron los requerimientos que debía cumplir

• Seguimiento de su desarrollo cumpliendo el rol decliente

• Validación de los distintos prototipos

• Un grupo de estudiantes de PIS desarrolló estaherramienta

El sitio web de ProTest fue generado automáticamentecon la herramienta DeVeloPro


41/45


DeVeloPro


42/45


Documentación de ProTest


43/45


Conclusiones ProTest modela las etapas de un proyecto de

pruebas• Guía útil para el equipo de prueba

• Usado actualmente en el Laboratorio de Testing

Funcional del CES• Documentado con DeVeloPro


44/45


Trabajo a Futuro

Probarlo en un contexto donde el cliente sea quiencompra el producto

Definir un proceso común a ambos laboratorios del CES.

Contar con datos históricos resultado de las medicionesintroducidas para realizar las actividades de ProTest

• A partir de estos datos se espera mejorar las estimaciones

Extender ProTest para la automatización de pruebasfuncionales

Instrumentación del Proceso• Uso de herramientas que ayuden en todo el proceso de

pruebas


45/45

PEDECIBA informática Instituto de Computación (InCo)

Facultad de Ingeniería

Universidad de la República.Montevideo, Uruguay

Gracias por su atención

¿Preguntas?

presentacion proceso de testing funcional independiente

Documents