La Calidad del Software y los Procesos de Testing. GFI Informática

Transcripción

1 La Calidad del Software y los Procesos de Testing GFI Informática

2 Índice Introducción. Visión general del proceso de pruebas. Metodologías de pruebas alineadas con procesos de desarrollo Uso de herramientas OpenSource Aspectos diferenciadores herramientas comerciales frente a OpenSource Factoría de pruebas

3 Índice Introducción. Visión general del proceso de pruebas. Metodologías de pruebas alineadas con procesos de desarrollo Uso de herramientas OpenSource Aspectos diferenciadores herramientas comerciales frente a OpenSource Factoría de pruebas

4 Introducción. Definición de calidad software La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario. (IEEE, Std ). Concordancia del software producido con los requerimientos explícitamente establecidos, con los estándares de desarrollo prefijados y con los requerimientos implícitos no establecidos formalmente, que desea el usuario (Pressman, 1998)

5 Introducción Visión General del Proceso de Pruebas El software lo desarrollan las personas, y éstas comenten errores; no se puede prevenir completamente la introducción de éstos defectos, pero si se puede trabajar para localizarlos especialmente los mas críticos. Decisiones de pruebas deberían basarse en satisfacción del cliente. Este es el objetivo último. Mayor parte de los defectos se concentran en las etapas tempranas del proceso de desarrollo y el costo de corrección aumenta a medida que permanece no detectado. De perogrullo: los defectos mas costosos son aquellos que no se detectan.

6 Introducción Visión General del Proceso de Pruebas El proceso de Pruebas es una parte del ciclo de vida del Software. Interviniendo desde la concepción detallada de la aplicación y colaborando hasta su puesta final en producción, dando así en su conjunto un alto nivel de calidad. Planificación Estandar Evolución Real Ideal Planificación Estandar Pruebas Evolución Real Ideal Pruebas REQUISITOS REQUISITOS DISEÑO ALTO NIVEL DISEÑO ALTO NIVEL DISEÑO DETALLADO DISEÑO DISEÑO DETALLADO DETALLADO CODIFICACIÓN CODIFICACIÓN INTEGRACIÓN INTEGRACIÓN CODIFICACIÓN PRUEBAS PRUEBAS INTEGRACIÓN INTEGRACIÓN PRUEBAS PRUEBAS

7 Introducción Algo mas que pruebas Software Pruebas Software Gestión del Ciclo de Vida de la Calidad Software

8 Introducción La falta de cualquiera de estos vertices implica problemas evidentes: Carencia Herramientas Metodología Problema Falta de Productividad Proceso caótico y no repetible Metodología Herramientas Recursos

9 Índice Introducción. Visión general del proceso de pruebas. Metodologías de pruebas alineadas con procesos de desarrollo Uso de herramientas OpenSource Aspectos diferenciadores herramientas comerciales frente a open-source Factoría de pruebas

10 Metodologías de Pruebas alineadas con procesos de desarrollo Introducción La evolución de los modelos específicos de test aumenta satisfactoriamente la calidad de dichos procesos y consecuentemente, los coloca en una posición relevante dentro de la ingeniería del software. Los modelos y estándares de evaluación de procesos de software ofrecen herramientas para establecer niveles de madurez de desarrollo y mantenimiento del software. Sin embargo, la sido constatado que estos modelos y estándares no dirigen adecuadamente sus enfoques a los procesos de test. En este sentido, se presentan, a continuación, tres modelos de evaluación y mejora de procesos de test: Acercamiento a la gestión de pruebas (Test Management Approach, TMap) Modelo de Mejora del Proceso de test (Test Process Improvement, TPI) Modelo de Madurez del Test (Test Maturity Model, TMM)

11 Metodologías de pruebas alineadas con procesos de desarrollo TMap TPI TMM

12 Metodologías - TMap La metodología TMAP, está basada en cuatro piedras angulares: Proceso de desarrollo relacionado con el modelo de ciclo de vida para las actividades de pruebas (L) Sólida Organización (O) Recursos e Infraestructura (I) Técnicas utilizables para varias actividades de pruebas (T)

13 Metodologías - TMap Modelo de ciclo de vida de Pruebas

14 Metodologías - TMap Técnicas

15 Metodologías - TMap Infraestructura y Herramientas

16 Metodologías - TMap Organización

17 Metodologías de pruebas alineadas con procesos de desarrollo TMap TPI TMM

18 Metodologías - TPI El modelo TPI está basado en las mejores prácticas de la industria relativas a la mejora del proceso de pruebas. El modelo incluye guías prácticas para evaluar el nivel de madurez de pruebas de una organización así como los pasos para mejorar el proceso. El propósito de tales mejoras podría ser alcanzar el nivel 3 del SEI- CMM ( Capability Maturity Model ). El modelo se compone de 20 Áreas Clave, cada una con diferentes niveles de madurez. Los niveles de todas las Áreas Clave están integrados en una Matriz de Madurez. Cada nivel está descrito por varios Puntos de Verificación. También forman parte del modelo algunas Sugerencias de Mejora que ayudan a alcanzar el nivel deseado.

19 Metodologías - TPI Niveles Puntos de Verificación Los requisitos para cada nivel están definidos en forma de Puntos de Verificación ( Checkpoints ): son preguntas que necesitan ser respondidas afirmativamente para poder calificar a dicho nivel. A partir de las listas de verificación se puede evaluar un proceso de pruebas y se puede determinar para cada Área Clave el Nivel alcanzado. A medida que se considera mejorada cada Área Clave, los Puntos de Verificación son acumulables: para poder clasificar para el nivel B, el proceso de pruebas necesita responder afirmativamente tanto a los Puntos de Verificación del nivel B como del nivel A.

20 Metodologías - TPI Matriz de Madurez Todos los Niveles y Áreas Clave están interrelacionados en una Matriz de Madurez de Optimizada (11-13) Pruebas. Se ha concebido como una buena manera de expresar las prioridades internas y Eficiente (6-10) dependencias entre Niveles y Áreas Clave. Controlada (1-5) No existe graduación entre Niveles: mientras que un proceso de pruebas no esté clasificado enteramente como nivel B, permanecerá en el nivel A. El propósito principal de la matriz es mostrar los puntos fuertes y débiles del actual proceso de pruebas y ofrecer una ayuda a la hora de determinar la prioridad de las acciones de mejora.

21 Metodologías - TPI Aplicación del Modelo TPI El proceso de mejora de pruebas es similar a cualquier otro proceso de mejora. La figura siguiente muestra las diferentes actividades de un proceso de mejora.

22 Metodologías de pruebas alineadas con procesos de desarrollo TMap TPI TMM

23 Metodologías - TMM El modelo TMM es un modelo de evaluación del proceso de test, guiado por el conjunto básicos de conceptos del CMM y compuesto por dos componentes principales: un conjunto de niveles de madurez y un modelo de evaluación.

24 Metodologías TMM: Conjunto de Niveles Se describe cada nivel considerando los objetivos de la organización y la capacidad de test. La estructura de cada nivel (excepto el primero), consiste en un conjunto de objetivos de madurez soportado por sub-objetivos (o metas) de madurez que son alcanzados por las actividades, tareas y responsabilidades. Las actividades y tareas representan las acciones que deben ser desempeñadas en cada nivel con el propósito de mejorar la capacidad del test Se asignan responsabilidades para las actividades y tareas, a los gestores, a los desarrolladores y testers y a los usuarios y clientes

25 Metodologías TMM: Modelo de Evaluación El Modelo de Evaluación consiste en un método que permite a la organización evaluar y mejorar sus procesos de test, basándose en un cuestionario de evaluación, un procedimiento de evaluación y el entrenamiento y criterios de selección del equipo de evaluación. Los objetivos de este componente son: proveer un esquema de evaluación de procesos de test de software y un fundamento para la mejora de dichos procesos a través de análisis de datos y planteamiento de acciones, así como contribuir con la ingeniería del proceso de software.

26 Índice Introducción. Visión general del proceso de pruebas. Metodologías de pruebas alineadas con procesos de desarrollo Uso de herramientas OpenSource Aspectos diferenciadores herramientas comerciales frente a open-source Factoría de pruebas

27 Uso de Herramientas Opensource Gestión del Ciclo de Pruebas Automatización de Pruebas Funcionales Pruebas de Carga Inspección de Código Pruebas Unitarias

28 Uso de Herramientas Opensource Gestión del Ciclo de Pruebas Automatización de Pruebas Funcionales Pruebas de Carga Inspección de Código Pruebas Unitarias

29 Gestión del Ciclo de Pruebas - Algunas Claves Documentar las pruebas Casos de prueba, estrategia de pruebas, ejecuciones Registrar los problemas encontrados Separar entornos y manejar configuraciones Ensayando la implementación Definir casos de prueba durante el análisis es una forma de documentar el producto Es una forma de adelantarnos al problema Testing independiente El que desarrolla no prueba Mayor experiencia y concentración Nadie está motivado para encontrar sus propios errores

30 Herramientas Opensource Herramienta de Gestión La gestión de las pruebas, requiere que la herramienta con la que se trabaje cumpla algunas características como: Soportar en paralelo el desarrollo de la aplicación y la gestión de las pruebas Trazabilidad de requisitos a pruebas gestionando ejecuciones así como defectos y su resolución Mejora la predictibilidad del proyecto Acceso en cualquier momento y lugar a pruebas e informes de ejecución Control centralizado Mejora la colaboración y comunicación entre equipos y proyectos Potencia la reutilización de objetos de prueba Acceso protegido a elementos del proyecto Sistema de informes Como ejemplo, se muestra la herramienta TestLink.

31 Herramientas Opensource Herramienta de Gestión TestLink, permite de manera intuitiva, la elaboración de casos de prueba, con los pasos a seguir para su posterior ejecución, así como de los resultados esperados, quedándose todo ordenado y accesible a través de un árbol de navegación.

32 Herramientas Opensource Herramienta de Gestión Durante todo el ciclo de vida se pueden obtener métricas tanto del los casos de prueba generados como de estado de la ejecución de los mismos.

33 Uso de Herramientas Opensource Gestión del Ciclo de Pruebas Automatización de Pruebas Funcionales Pruebas de Carga Inspección de Código Pruebas Unitarias

34 Herramientas Opensource Automatización Pruebas Funcionales Las herramientas de Automatización de pruebas funcionales cumplen el siguiente ciclo de trabajo: Planificación de pruebas automáticas Registro de las acciones de usuario Control y verificación de los Checkpoints Comprobación resultado esperado = resultado obtenido Gestión del mapa de interfaz de usuario Testing modular y batch Como ejemplo, tenemos la herramienta Selenium, que nos permite la operativa de trabajo descrita.

35 Herramientas Opensource Automatización Pruebas Funcionales Primeramente, se graban las acciones del usuario sobre la aplicación, quedándose éstas recogidas en la aplicación para su posterior tratamiento, que se realizará modificando el código generado Prácticamente la totalidad de las herramientas Opensource, trabajan solo sobre aplicaciones Web.

36 Herramientas Opensource Automatización Pruebas Funcionales Los casos de prueba, pueden ser modificados para introducir puntos de control, pausas, verificaciones, etc. La ejecución de los mismos se puede planificar, agrupando casos y programándolos. Se obtienen informes sobre los resultados de las ejecuciones.

37 Uso de Herramientas Opensource Gestión del Ciclo de Pruebas Automatización de Pruebas Funcionales Pruebas de Carga Inspección de Código Pruebas Unitarias

38 Herramientas Opensource Pruebas de Carga Las herramientas para la realización de pruebas de Carga, tiene las siguientes funcionalidades Planificación de pruebas de carga Creación de los escenarios de prueba Simulación de n usuarios concurrentes Análisis de resultados de ejecución de los distintos escenarios A continuación podemos ver la operativa ejemplificada con la herramienta OpenSta

39 Herramientas Opensource Pruebas de Carga Para la ejecución del test, se introducen datos como número de usuarios, scripts que compondrán la ejecución y elementos a ser testados como % Cpu,memoria, etc...

40 Herramientas Opensource Pruebas de Carga Durante la ejecución de la prueba, se puede monitorizar todos los recursos que sean de nuestro interés.

41 Herramientas Opensource Pruebas de Carga Posteriormente a la ejecución, se pueden obtener tanto log como gráficas con las estadísticas de la prueba. Algunas de ellas son las de puntos de medida respecto del tiempo, puntos de medida respecto del número de usuarios, número de usarios activos, errores HTTP, etc

42 Uso de Herramientas Opensource Gestión del Ciclo de Pruebas Automatización de Pruebas Funcionales Pruebas de Carga Inspección de Código Pruebas Unitarias

43 Uso de Herramientas Opensource. Inspección de Código Las inspecciones del código tienen el objetivo de detectar aspectos que influyen en la calidad de éste: Errores de ejecución Mermas de rendimiento Código muerto Redundancia de código Incumplimiento de arquitectura Incumplimiento de estándares técnicos a nivel de codificación. Mantenibilidad del código Metodología de trabajo: Priorización: Se suele aplicar orientación al riesgo. Medición: Uso de herramientas de análisis. Se obtienen métricas de nivel técnico que permiten la detección de incumplimientos y/o deficiencias, cuyo conjunto se expresa en: Informes de auditoria. Plan de mejora. Informe de recomendaciones para la mejora.

44 Uso de Herramientas Opensource. Inspección de Código Entrega de una nueva versión Nueva versión software Publicar versión Integración continua Generación informes Publicación informes Notificación vía mail Generación informe SAC Se realiza la entrega de una nueva versión de software por parte del proveedor.

45 Uso de Herramientas Opensource. Inspección de Código Publicación de la nueva versión Nueva versión software Publicar versión Integración continua Generación informes Publicación informes Notificación vía mail Generación informe SAC El jefe de proyecto publica el entregable en el repositorio común CVS Herramientas: CVS: Implementa un sistema de gestión de versiones. Mantiene el registro de todo el trabajo y los cambios en la implementación de un proyecto, permitiendo la colaboración entre distintos desarrolladores. Es un referente en software libre de gestión de versiones.

46 Uso de Herramientas Opensource. Inspección de Código Proceso de integración continua Nueva versión software Publicar versión Integración continua Generación informes Publicación informes Notificación vía mail Generación Informe SAC El proceso de integración continua (automático) detecta la nueva versión en el repositorio y ejecuta un conjunto de tareas programadas Herramientas: Continuum v1.0.2: Servidor de integración continua. Realiza tareas programadas sobre proyectos basados en java. Alto grado de integración con Maven.

47 Uso de Herramientas Opensource. Inspección de Código Notificación vía mail Nueva versión software Publicar versión Integración continua Generación informes Publicación informes Notificación vía mail Generación Informe SAC Se notificará por mail, al conjunto de usuarios definidos, la nueva entrega.: Jefe de proyecto. SAC. Etc.

48 Uso de Herramientas Opensource. Inspección de Código Generación de informes automáticamente Nueva versión software Publicar versión Integración continua Generación informes Publicación informes Notificación vía mail Generación informe SAC Herramientas: Changelog v1.8.2 QALab v0.7.2 CheckStyle v2.5 JavaDoc Reporte v1.7 Jcoverage v1.0.9 Jdepend v1.5 NCSS v1.3 Pmd v1.6 FindBugs v0.9.2 File-Activity Se generarán automáticamente los informes de calidad programados.

49 Uso de Herramientas Opensource. Inspección de Código Publicación de Informes Nueva versión software Publicar versión Integración continua Generación informes Publicación informes Notificación vía mail Generación informe SAC Herramientas: Maven v1.0.2: Herramienta para la gestión y comprensión de proyectos java. Estándar de mercado en el mundo free. Metodología XP. Se publicarán de forma automática los informes generados en el portal de calidad Herramientas: Apache v utilizada por explotación: Servidor http referente del mercado.

50 Uso de Herramientas Opensource. Inspección de Código Generación de resumen Nueva versión software Publicar versión Integración continua Generación informes Publicación informes Notificación vía mail Generación informe SAC El SAC generará un informe con los resultados de las inspecciones realizadas al código: Resumen ejecutivo (dirección). Detalle técnico (equipo técnico).

51 Uso de Herramientas Opensource. Inspección de Código Arquitectura Internet Internet CVS desarrollo Continuum Apache Equipo desarrollo SAC Responsable proyecto CVS SAC (entregas) Maven Desarrollo Gestión versiones Recursos SAC Frontal Preexplotación Explotación

52 Uso de Herramientas Opensource Gestión del Ciclo de Pruebas Automatización de Pruebas Funcionales Pruebas de Carga Inspección de Código Pruebas Unitarias

53 Herramientas Opensource Pruebas Unitarias El peso de la generación de las pruebas unitarias recae sobre el equipo de desarrollo. La responsabilidad del equipo de SQA es la de ejecutar el conjunto de pruebas unitarias, validar los resultados y medir el grado de cobertura de las mismas. El conjunto de pruebas unitarias proporcionadas por el equipo de desarrollo debe cumplir los siguientes normas: Ejecutables de forma automática. Independencia del entorno. Autocontenidas. Preprocesamiento. Ejecución. Postprocesamiento. A continuación se muestra un ejemplo de la labor del equipo de SQA en un conjunto de pruebas basadas en Junit y Cobertura.

54 Herramientas Opensource Pruebas Unitarias Junit es un framework ampliamente utilizado para la automatización de pruebas unitarias. El equipo SQA ejecutará las pruebas unitarias proporcionadas por el equipo de desarrollo obteniendo un informe con el resultado de la ejecución de las mismas.

55 Herramientas Opensource Pruebas Unitarias Cobertura es una herramienta opensource que mide la cobertura de las pruebas por medio de la instrumentalización del código y la posterior medición de las líneas de código ejecutadas por el conjunto de casos de prueba unitarios. El equipo de SQA instrumentalizaría el código y posteriormente ejecutaría el conjunto de pruebas unitarias analizando los resultados.

56 Herramientas Opensource Pruebas Unitarias A continuación se muestra una salida estándar de la herramienta:

57 Herramientas Opensource Pruebas Unitarias Cobertura calcula la cobertura de las pruebas contabilizando: Número de líneas de código ejecutadas. Número de ramas ejecutadas. Adicionalmente Cobertura calcula la complejidad ciclomática (Mc-Cabe) de cada una de las clases.

58 Herramientas Opensource Pruebas Unitarias La herramienta permite realizar drill-down para visualizar la cobertura de las clases pertenecientes a un determinado paquete Y llegar al máximo detalle visualizando las líneas de código ejecutadas en una determinada clase

59 Herramientas Opensource Pruebas Unitarias Esta herramienta permite al equipo de SQA validar el porcentaje de cobertura de las pruebas unitarias realizadas por el equipo de desarrollo, identificando módulos poco probados o no probados. Los resultados de la herramienta permiten ampliar el plan de prueba unitario con casos de prueba específicos que cubran el código no testeado. También permite identificar porciones de código muerto que no es posible ejecutar.

60 Índice Introducción. Visión general del proceso de pruebas. Metodologías de pruebas alineadas con procesos de desarrollo Uso de herramientas OpenSource Aspectos diferenciadores herramientas comerciales frente a Opensource Factoría de pruebas

61 Aspectos diferenciadores Herramientas comerciales frente a Opensource Ventajas OpenSource Coste licencias es nulo! Construidas con los mismos principios que las comerciales: Arquitectura Metodología/Técnicas Extensibles/Integrables (Código abierto) En algunos casos y para ciertos entornos, son más potentes que las comerciales! Inconvenientes OpenSource Normalmente sólo disponibles para entornos web/java Entornos de desarrollo espartanos En ocasiones, lenguajes propietarios En su desarrollo prima la funcionalidad básica frente a la avanzada y/o utilidades/gadgets El aprendizaje suele ser costoso Material de formación muy básico o inexistente No suele disponerse de guidelines metodológicos Estabilidad/Fiabilidad El soporte suele ser una incógnita (comunidades de usuarios/desarrolladores). Normalmente es escaso o nulo

62 Aspectos diferenciadores Herramientas comerciales frente a Opensource Ventajas Comerciales Multientorno: web/java, middleware, C/S, legacy (mainframe) Entornos de desarrollo IDE gráficos plenos de utilidades Lenguajes abiertos Entornos de ejecución con herramientas de análisis, monitorización, diagnóstico, Robustez y Escalabilidad Arquitecturas tolerantes a fallos Metodología/Técnicas: El fabricante aporta las suyas propias Integradas Por supuesto las de un mismo fabricante En muchas ocasiones, entre fabricantes Integrables (mediante APIS) Herramientas de Reporting potentes Integradas con paquetes ofimáticos con su correspondiente plantillaje Dashboards ejecutivos (Web) Soporte técnico solvente ( cuesta, pero existe!) Inconvenientes Comerciales Coste licencias. Suele asustar!

63 Aspectos diferenciadores Herramientas comerciales frente a Opensource Conclusiones: Empezar con opensource no es mala idea: En entornos web/java exclusivamente Las herramientas funcionan Parte del conocimiento adquirido es reaprovechable. Pero ojo, hay que tener en cuenta los costes! Hay un sobreesfuerzo asociado al uso de opensource con respecto a comerciales (la productividad no es la misma) que hay que tener en cuenta: Un proyecto grande o varios proyectos pequeños pueden justificar la inversión en comerciales Migrar de opensource a comerciales tiene un coste de reciclaje técnico Definitivamente, en algún momento tendremos que adquirir alguna herramienta comercial: Por adecuación al entorno Por limitaciones en la funcionalidad de las opensource Por necesidades de reporting avanzado Por capricho? A quién no le gusta el Ferrari?

64 Herramientas Comerciales Gestión n de Pruebas Automatiza- ción Carga y Estrés Reporte de Incidencias Pruebas Manuales

65 Índice Introducción. Visión general del proceso de pruebas. Metodologías de pruebas alineadas con procesos de desarrollo Uso de herramientas OpenSource Aspectos diferenciadores herramientas comerciales frente a Opensource Factoría de pruebas

66 Factoría de Pruebas - Conceptos Grupo dedicado que provee testing como un servicio compartido Emplea un conjunto de personas que se especializan en uno o múltiples tipos de testing o uno o mas dominios de negocio o tecnológicos. Entre los roles de una Factoría de Pruebas se pueden incluir: Definición de los procesos y estándares de testing a ser adoptados por los proyectos Implantación de los procesos y estándares definidos Provisión de personal cualificado y entrenado a los proyectos Planificación y ejecución de testing para varios proyectos

67 Factoría de Pruebas- Tradicional vs FdP Acercamiento Tradicional Se contrata al equipo de test por proyecto, dependiendo de la disponibilidad de los recursos Los desarrolladores se emplean como testers durante las últimas etapas del proyecto Se dedican diferentes testers durante las diferentes etapas del proceso de testing o a través de diferentes proyectos Los procesos de testing son implementados inconsistentemente a través de los proyectos Posible duplicación de habilidades y entrenamiento a través de los diferentes proyectos Factoría de Pruebas Se contrata al equipo de test para múltiples proyectos basados en compromisos Se emplean tester especializados con habilidades y que han sido entrenados para realizar testing Se dedica un pool de recursos de testing para uno o mas proyectos Se aprovechan los procesos de testing a través de los diferentes proyectos Consistencia Se aprovecha óptimamente las diversas habilidades a través de los diferentes proyectos

68 Factoría de Pruebas Requisitos de una Factoría de Pruebas Centro de pruebas externo Proyectos de Pruebas Interlocución a través del cliente Ciclo de vida iterativo incremental Entregar código fuente Entornos altamente emulables Pruebas 80% caja negra

69 Factoría de Pruebas Funcionalidad Gestión de la configuración SW Gestión de Clientes Aseguramiento de la Calidad Gestión de Pruebas Help Desk Seguridad

70 Factoría de Pruebas Operativa

71 Factoría de Pruebas Perfil del Proveedor Experiencia probada en: Trabajar ( testear ) en el entorno de negocio del Cliente Trabajar en formato Factoría de Pruebas, con todas sus implicaciones Comunicación Gestión del proceso Gestión de la Infraestructura Formación Alcance de su experiencia Tipos de Test Entornos de Test Testing basado en riesgo Experiencia en su dominio específico del negocio Empleados propios y con experiencia en testing Disponibilidad de equipamiento, infraestructura, herramientas Flexibilidad y adaptabilidad Niveles de servicio ofrecidos

72 Factoría de Pruebas Composición del Equipo

73 Factorías de Pruebas focalizadas en el cliente Equipo base + recursos bajo demanda Diferentes acercamientos Focalizados en tipo de testing Web Testing, Load and Performance testing, Localización Focalizados en herramientas Focalizados en Tecnologías Web,.Net, Java, Cliente/Servidor, Mainframe Mayores ventajas hacia nuestros clientes en términos de: Competencias técnicas Reutilización de infraestructuras, test wares... Retención de conocimiento Optimización de los procesos

74 Factoría de Pruebas Que ha funcionado con los clientes Desafíos iniciales Justificación de costos iniciales para el cliente Falta de sinergia a través de diferentes áreas de negocio del cliente Sin certeza de por donde empezar y como proceder Conflictos entre estandarización del proceso y el ahorro del costo a través del outsourcing Como los superamos Fase Piloto/Pruebas de concepto (área de bajo riesgo) Establecimiento de un modelo compartido de servicios de testing, recursos del cliente y del proveedor trabajando muy cerca Se comienza en pequeño, llevando un área cada vez al modelo de Factoría de Pruebas. Opción A: Se comienza con una evaluación, a través de las diferentes áreas para analizar y recomendar estandarización de procesos Opción B: Un área o aplicación en concreto, en base a las prioridades existentes Se comienza a incrementar la carga de trabajo/proyectos/áreas a medida que la confianza va creciendo

75 Factoría de Pruebas Flexibilidad bajo demanda Mejorar el uso de los recursos internos optimizando los periodos de sobrecarga Introducir su producto en el mercado mas rápido Arranque inmediato Absorber los retrasos y cambios repetitivos

76 Factoría de Pruebas SLA: Acuerdo de Nivel de Servicio Criticidad 1 2 Criticidad 1 2 Criticidad 1 2 FASE DE ANALISIS DISEÑO Y CONSTRUCCIÓN Indicador Valor Objetivo =0% requisitos no incorporados en la solución =100% 3 iteraciones >90% =10% requisitos no incorporados en la solución =100% 3 iteraciones >90% FASE DE PRUEBAS Indicador Valor Objetivo 20% sobre el total de pruebas en el plan de pruebas >90% 3 iteraciones >90% 40% sobre el total de pruebas en el plan de pruebas >90% 2 iteraciones >90% FASE DE IMPLANTACIÓN/PASO A PRODUCCIÓN Indicador Valor Objetivo 10% nº de componentes instalados respecto a la planificación >90% 2 iteraciones >90% 20% nº de componentes instalados respecto a la planificación >90% 2 iteraciones >90%

77 Factoría de Pruebas Conclusiones Las Factorías de Pruebas son un concepto focalizado en el outsourcing estratégico del testing Las Factorías de Pruebas centradas en el cliente pueden ofrecer significativos beneficios ya que están enfocados a mejorar continuamente en base a la experiencia y el conocimiento El valor del negocio del test outsourcing puede ser medido y mejorado a través de un programa de métricas consensuado

78 Ruegos y Preguntas Automatización del Servicio Automatización de las actividades de SQA: análisis de código, ejecución de casos, reporte de defectos, gestión de pruebas Validación Funcional Test de caja negra basados en los requisitos y las especificaciones funcionales Pruebas de Carga Conjunto de pruebas dinámicas que aseguran el comportamiento del sistema en determinados escenarios Test de Usabilidad Validación del diseño y facilidad de uso de los interfaces de usuario, siguiendo los estándares de mercado Revisión de la seguridad del código Revisión de la seguridad de las aplicaciones, principalmente web ante las vulnerabilidades conocidas Inspección documental Validación, verificación y trazabilidad de requisitos y documentación funcional Test de Caja Blanca Revisión del diseño y codificación de las distintas capas: Interfaz de usuario, datos e integración

79 Gracias