Endorsed by: Patrocinadores. Platinum. Gold. Programa expo:qa 09 INDICE

Transcripción

1

2

3 INDICE - rograma resumido 5 rograma expo:qa 09 - Taller Hands-on IBM 8 - Tutoriales 8 - Conferencia 11 - Expositores 20 - Colaboradores 20 - Cena Networking 23 - recios 24 QUIÉN ORGANIZA EXO:QA? Nexo QA es una empresa independiente cuya vocación es promover la implantación de buenas prácticas en el sector de las TICS y la Ingeniería del Software. Nexo QA organiza conferencias, seminarios, talleres o cursos (abiertos o privados) que cuentan con la presencia de expertos reconocidos internacionalmente. Nexo QA organiza la Conferencia Internacional de Testing y Calidad del software - expo:qa - cuya primera edición tuvo lugar en el 2004 y que se ha convertido en el encuentro de referencia de los expertos del sector en España. Endorsed by: 3 atrocinadores latinum Gold

4

5 rogramaresumido HORARIO 09:00-17:00 T Lunes 26 de octubre Taller interactivo Taller hands on interactivo sobre la solución de gestión centralizada de pruebas IBM Rational Quality Manager. Este taller es gratuito para los asistentes a expo:qa 09. Aforo limitado. Sergio López 09:00-17:00 TU Martes 27 de octubre Real QA - Un control de calidad real desde un punto de vista ágil y Lean: está preparado para un software y una ingeniería de pruebas reales? El testing tradicional, como medio para conseguir el control de calidad, es demasiado costoso e ineficaz. Existen muchas maneras más inteligentes de abordar la calidad del software. Un problema es saber quién dirigirá el proceso de cambio. Este tutorial describirá una función de QA mucho más avanzada y desafiará al gerente de sistemas y a la dirección técnica para que la implementen. Como material de referencia del tutorial se ofrece el Real QA Manifesto promovido por Tom Gilb. Tom Gilb 09:00-17:00 TU GUI Bloopers: cómo reconocer y evitar los errores comunes en el diseño de una GUI El libro de diseño de interfaces de usuario, GUI Bloopers: Don ts and Dos for Software Developers and Web Designers, se convirtió rápidamente en un referente clásico para desarrolladores de software y diseñadores web. Ha recibido críticas positivas en revistas, publicaciones especializadas y librerías en línea. Este tutorial se basa en la nueva edición del libro GUI Bloopers 2.0: Common User Interface Design Don ts and Dos. Jeff Johnson 5 09:00-17:00 TU Gobernabilidad del Testing La gobernabilidad del testing es la inversión justificada del cliente en testing para así conocer los riesgos y resultados deseados en un límite de tiempo determinado. El tutorial o taller se basa en la teoría de la Gestión de pruebas orientada al negocio. aso a paso y con la ayuda de listas de comprobación, los propios participantes realizan una exploración rápida de gobernabilidad del testing en un proyecto de testing de su propia organización. Después del tutorial, los propios participantes son capaces de determinar si este proyecto cumple o no con los requisitos de la gobernabilidad del testing. En caso negativo, se ofrecerán recomendaciones al participante para mejorar. Leo Van der Aalst TALLER TUTORIALES ONENCIAS con traducción

6 09:00-09:30 09:30-09:35 09:35-11:00 11:00-11:30 Miércoles 28 de octubre Registro Apertura Raynald Korchia Keynote: Cómo evaluar si la especificación de requisitos es suficientemente buena para el testing: el proceso de inspección ágil y la salida numérica Tom Gilb Coffee Break patrocinado por IBM Track 1 atrocinado por ORACLE (Traducción simultánea) Track 2 (Traducción simultánea) Track 3 11:30-12:30 Testing exploratorio automatizado Ayal Zylberman Una visión practica del aseguramiento de la calidad de software Salvador Folgado Seguridad en la aplicación: concienciación Martin Knobloch 12:30-13:30 El testing de software efectivo es fácil Siva Kannan Testing y SCRUM: Caso de Estudio Claudia Badell Tendencias y posibilidades del análisis estático y dinámico de código José Ramón Martínez Salio 6 13:30-15:00 15:00-16:00 Almuerzo patrocinado por H Rational Quality Manager. Novedades y mejoras en la gestión de pruebas. Sergio López 16:00-17:00 El modelo en V múltiple: todavía en plena forma? André Verschelling Gestión efectiva de la calidad de un producto software Antonio Sepúlveda Carrero Calidad del Desarrollo Software con Visual Studio, Microsoft Test y Lab Management José Murillo 17:00-17:30 Coffee Break patrocinado por IBM 17:30-18:30 ruebas de rendimiento, carga, estress... hablamos todos de lo mismo? Realización de un proyecto de pruebas multiemplazamiento con herramientas basadas en WEB ruebas efectivas mediante Six Sigma José Aracil Leticia Zárate Casanova Teodora Bozheva CENA NETWORKING ara que puedan encontrarse y conocerse ponentes y asistentes en un ambiente relajado y confortable! Después de un intenso día de conferencia, le proponemos olvidar la dura realidad del testing ( o no!), estar a gusto y disfrutar juntos en un lugar excepcional cargado de historia, el Casino de Madrid. TALLER TUTORIALES ONENCIAS con traducción

7 Jueves 29 de octubre Track 1 atrocinado por ORACLE (Traducción simultánea) Track 2 (Traducción simultánea) Track 3 09:00-10:00 Ahorro de tiempo tremendo con la técnica de pruebas adecuada Leo Van der Aalst 10:00-11:00 Agile con Quality Center de H Miguel Ángel Rial Coste de la calidad y de la no Calidad Augusto Sagrario érez La calidad objetiva: Métricas e indicadores Miguel Angel Cervera Roig 11:00-11:30 Coffee Break patrocinado por STERIA 11:30-12:30 Modelo SOA TMA Antonio Luque Blancanieves y los siete enanitos: Gerente de pruebas en un equipo ágil Davor Crnomat Cómo medir la calidad en la entrada, no solo en la salida Jan Fish 12:30-13:30 Automatización de pruebas - Hablemos de negocios Igor Gershovich Cómo ayudamos a nuestros clientes a industrializar los procesos de pruebas Stéphane Ayache Implantación de un Centro de Calidad y Testing Xavier Escudero Sabadell 13:30-15:00 Almuerzo patrocinado por MICROSOFT 15:00-16:30 Keynote: El valor empresarial de la usabilidad Jeff Johnson 7 16:30-17:30 Requisitos y ruebas. Un modelo eficiente para gestionar las dependencias El control de calidad del Single Source of Truth puede ir a la par de un entorno ágil Gestión de pruebas para programas muy grandes: kit de supervivencia José Manuel Muñoz Nicole Zanetti Graham Thomas 17:30-17:40 Clausura y Sorteo del participante ganador expo:qa 09 17:40-18:00 Coffee Break de despedida patrocinado por STERIA TALLER TUTORIALES ONENCIAS con traducción

8 Taller Sergio López IBM, España Sergio López es técnico de preventa de Software de IBM Rational. Actualmente desarrolla su carrera profesional en IBM Rational como especialista de Software de gestión de la calidad. Anteriormente ha trabajado en IBM como técnico especialista de desarrollo de aplicaciones web durante más de ocho años. Fecha: 26/10/2009 Taller interactivo Taller hands on interactivo sobre la solución de gestión centralizada de pruebas IBM Rational Quality Manager. Se realizarán una serie de ejercicios prácticos con los cuales los asistentes puedan obtener un conocimiento general de la solución IBM Rational Quality Manager para la gestión centralizada de las pruebas, así como de las nuevas funcionalidades de la versión 2.0. Este taller es gratuito para los asistentes a expo:qa 09. Aforo limitado. onente: Sergio López 8 Tutoriales Tom Gilb EE.UU./UK/Noruega Tom Gilb (nacido en 1940, California) ha vivido en el Reino Unido desde 1956 y en Noruega desde Ha publicado nueve libros, incluido el titulado Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using language, Ha impartido clases y ha trabajado como consultor en todo el mundo durante décadas, además de influir directamente en el cambio de métodos corporativos de corporaciones destacadas como Intel, H, IBM y Nokia. Su influencia fundamental en la Cultura ágil se ha documentado especialmente con la idea clave común del desarrollo iterativo. Ha acuñado el término métricas del software con el que tituló uno de sus libros, publicado en Es coautor, junto a Dorothy Graham, del método de testing estático Software Inspection (1993). Son conocidas sus estimulantes y avanzadas presentaciones así como su manera de evitar sistemáticamente la cultura popular simplificada en exceso que habitualmente tienta a los programadores inmaduros a perder el tiempo y hacer que sus proyectos fracasen. ara obtener más información visite TALLER TUTORIALES ONENCIAS Fecha: 27/10/2009 Real QA - Un control de calidad real desde un punto de vista ágil y Lean: está preparado para un software y una ingeniería de pruebas reales? Contexto del tutorial: El testing tradicional, como medio para conseguir el control de calidad, es demasiado costoso e ineficaz. Existen muchas maneras más inteligentes de abordar la calidad del software. Un problema es saber quién dirigirá el proceso de cambio. Este tutorial describirá una función de QA mucho más avanzada y desafiará al gerente de sistemas y a la dirección técnica para que la implementen. Definiciones: Ágil, simplificado, significa capacidad de aprender y cambiar rápidamente. Lean, simplificado, significa centrarse en el Valor y evitar la burocracia que no aporta valor. Los ideales están en Scrum y, a continuación, se ofrecen algunas prácticas de ingeniería como cortesía para desarrolladores profesionales y desarrolladores a gran escala. Contenido del tutorial: Todas las partes verdaderamente implicadas: hay muchas (de 30 a 40) y diferentes partes implicadas que se deben considerar en un QA: no solo el usuario y el cliente. Se trata de una responsabilidad del tipo ropietario de producto Scrum: pero, funciona bien en la práctica? Creemos que no, y tenemos consejos constructivos para mejorarla. Todos los requisitos de calidad cuantificados: requisitos de calidad multidimensionales cuantificados para definir la calidad relevante al proyecto en el control de calidad. La calidad es mucho más que la eliminación de defectos. Gestionar diseños con los que conseguir calidades: impacto estimado de los diseños y las arquitecturas sobre los niveles de requisitos como base para asegurar que posteriormente se han conseguido los niveles de calidad planeados. Cómo gestionar diferentes calidades de manera cuantitativa. Medición ligera de requisitos y especificaciones: todas las comprobaciones de calidad (QC) ágiles de las especificaciones (Spec QC). Incluye requisitos, diseños, códigos y pruebas que ofrecen una motivación sólida para seguir las mejores prácticas estándares mejor según un factor de 100. La calidad abre paso al trabajo: los estándares numéricos de entrada y salida de los procesos (mejora x100) para el cumplimiento de los estándares de la especificación: se agradecerá que no haya información superflua. roceso práctico para la prevención de defectos: mejora del proceso real de manera anticipada, frecuente y cuantificable en todos los proyectos. Iteración evolutiva rápida: realizar un QA real semanal e incremental. Entrega de valor incremental, recogida de datos, comentarios, análisis y cambio: para una entrega de valor anticipada, para el control de costes, para establecer unas prioridades inteligentes, para la validación de la eficacia del equipo y del proceso. Cuantificar requisitos de mantenimiento: pensamiento a largo plazo sobre las capacidades de mantenimiento y cambio: evitar una visión limitada. Estudio de caso de un QA real - Confirmit, Noruega: calidades cuantificadas en primer plano. Incluidas sus prácticas de testing. Mediante el método Evo de Gilb. Estudio de caso: IBM Cleanroom, Harlan Mills. Ciclos 2% evolutivos, inspecciones, disciplina para no inyectar defectos, diseño según coste y testing de muestreo. Seminario impartido en inglés. lazas limitadas. onente: Tom Gilb con traducción

9

10 Jeff Johnson UI Wizards, EE.UU Consultor Director Yale University B.A., Stanford University h.d. Jeff Johnson cuenta con más de 28 años de experiencia en el sector informático, donde ha diseñado, implementado, evaluado y testeado interfaces de usuario en Cromemco, Xerox, US West, Hewlett- ackard y Sun Microsystems antes de convertirse en consultor. Concretamente: tiene una amplia experiencia en el diseño y ejecución de pruebas de usabilidad objetivas y sistemáticas. Especialmente: tiene experiencia en organizar instalaciones de testings de usabilidad. es un experimentado ponente y profesor. ha trabajado anteriormente como profesor auxiliar en ciencias informáticas en el Mills College. ha trabajado anteriormente como ponente a tiempo parcial sobre la Interacción persona-ordenador en la Stanford University. Erskine Teaching Fellow, University of Canterbury, Christchurch, Nueva Zelanda, Múltiples publicaciones sobre la interacción persona-ordenador, incluidos los libros: GUI Bloopers: Don ts and Do s for Software Developers and Web Designers Web Bloopers: 60 Common Web Design Mistakes and How to Avoid Them GUI Bloopers 2.0: Common User Interface Design Don ts and Dos Experto respetado en el campo de la Interacción persona-ordenador. Consultor desde julio de Fecha: 27/10/2009 GUI Bloopers: cómo reconocer y evitar los errores comunes en el diseño de una GUI Este tutorial se basa en el libro GUI Bloopers 2.0: Common User Interface Design Don ts and Dos. El libro explica cómo evitar errores comunes en el diseño de una Interfaz de Usuario Gráfica y ofrece ejemplos de software comercial y sitios web. El tutorial trata los errores más específicos que se describen en el libro: de control de la GUI, de navegación, de texto, de diseño gráfico y de interacción. La versión del tutorial de todo el día incluye ejercicios de clase para que los alumnos revisen la GUI de productos y sitios web que el profesor y los participantes aportan a la clase. Está dirigido a diseñadores y desarrolladores de software, especialmente a los que no tienen muchos años de experiencia en el diseño y la evaluación de GUI, y a testers que quieren manipular y mejorar las interfaces de usuario que tienen que testear. Después de completar esta clase, los alumnos: * conocerán los errores más comunes en el diseño de una GUI y las maneras de evitarlos. * podrán reconocer estos errores en productos de software y software para web. * serán mejores diseñadores y clientes de software interactivo y de servicios en línea. Seminario impartido en inglés. lazas limitadas onente: Jeff Johnson Fecha: 27/10/2009 Gobernabilidad del Testing 10 Leo Van der Aalst SOGETI, aises Bajos Tras una trayectoria tradicional por las TI (desde programador hasta gestor de proyectos) Leo van der Aalst se ha especializado desde 1990 en el ámbito del testing, en el que ha desempeñado cargos como gerente de testing, consejero de testing, director de investigación y desarrollo y director de operaciones. Como director de desarrollo del negocio es coautor de los libros de TMap NEXT y TMap NEXT BDTM y ha desarrollado entre otros servicios en la implementación de organizaciones de testing, la externalización de pruebas y la gobernabilidad del testing. Leo también ha diseñado los ejercicios del EXIN para el TMap NEXT Foundation así como para el examen Avanzado y ofrece formación preparatoria para estos exámenes. Además, Leo trabaja como profesor adjunto de calidad y testing de software en la comunidad Fontys Hogescholen. Leo ha aplicado sus conocimientos y su experiencia en el campo de la gestión de pruebas y proyectos durante diversos proyectos internacionales y trayectorias de consultoría (en los EE.UU., Alemania, Dinamarca y Austria). Además de todo esto, Leo es un profesor muy solicitado en la formación para testing y un ponente habitual en conferencias nacionales e internacionales (entre otros, STARWEST y NSQC (ambas en los EE.UU.), EUROSTAR (Europa), Test Congress y Test Expo (ambas en el Reino Unido), Test2008 (India), Quality Week Europe (Bélgica), ICSTEST y TAV (ambas en Alemania) y QA&TEST (España)). También es autor de varios artículos (entre otros, sobre cómo calcular el valor añadido del testing, el testing basado en los riesgos y las ventajas de un centro de servicio de testing). La gobernabilidad del testing es la inversión justificada del cliente en testing para así conocer los riesgos y resultados deseados en un límite de tiempo determinado. Introducción Todos conocemos las causas que han originado la crisis económica actual, pese a todas las normativas de gobernabilidad corporativa (SOX, SAS70, entre otras). Leo cree que el mundo del testing tiene que mejorar su trabajo. or eso hemos de pensar en la gobernabilidad del testing, es decir, en la manejabilidad y la justificación del testing. Los clientes están muy interesados en la gobernabilidad del testing. De hecho, más de 10 clientes (hasta ahora) han solicitado que Leo imparta un taller sobre este tema en la localidad del cliente. Taller Al testear, es necesario encontrar el equilibrio entre el testing intenso (reduce el daño potencial y genera confianza) y el testing ligero (costes menores y plazos de entrega más cortos). La gobernabilidad del testing trata del testing manejable que permite la transparencia y la justificación del gasto en testing en relación a los beneficios. Un proyecto de testing tiene que cumplir con las expectativas de la definición de gobernabilidad del testing y ser capaz de responder las preguntas siguientes con un sí : 1. El enfoque de las pruebas, tiene como meta obtener un resultado predefinido (objetivo del testing)? 2. El gasto de tiempo y dinero (costes) para realizar el proyecto de testing, está compensado con los resultados que se tienen que conseguir y los riesgos que se deben asumir (beneficios), como desea la organización? 3. Se puede llevar a cabo un seguimiento de las decisiones tomadas en el proyecto de testing? 4. Las decisiones tomadas en el proyecto de testing, están en consonancia con los riesgos que se deben asumir, la cantidad de tiempo y dinero disponible y el resultado que la organización desea conseguir? 5. Se puede llevar a cabo un seguimiento de los casos de testing en relación a los objetivos del testing? 6. Se han creado casos de testing apropiados en consonancia con la estrategia de testing acordada? El tutorial o taller se basa en la teoría de la Gestión de pruebas orientada al negocio. aso a paso y con la ayuda de listas de comprobación, los propios participantes realizan una exploración rápida de gobernabilidad del testing en un proyecto de testing de su propia organización. Después del tutorial, los propios participantes son capaces de determinar si este proyecto cumple o no con los requisitos de la gobernabilidad del testing. En caso negativo, se ofrecerán recomendaciones al participante para mejorar. úblico Gerentes de pruebas Analistas de pruebas Ingenieros de pruebas Gestores de proyectos Directores de desarrollo Directores empresariales Seminario impartido en inglés. lazas limitadas. onente: Leo Van der Aalst con traducción

11 Conferencias Tom Gilb EE.UU./UK/Noruega Tom Gilb (nacido en 1940, California) ha vivido en el Reino Unido desde 1956 y en Noruega desde Ha publicado nueve libros, incluido el titulado Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using language, Ha impartido clases y ha trabajado como consultor en todo el mundo durante décadas, además de influir directamente en el cambio de métodos corporativos de corporaciones destacadas como Intel, H, IBM y Nokia. Su influencia fundamental en la Cultura ágil se ha documentado especialmente con la idea clave común del desarrollo iterativo. Ha acuñado el término métricas del software con el que tituló uno de sus libros, publicado en Es coautor, junto a Dorothy Graham, del método de testing estático Software Inspection (1993). Son conocidas sus estimulantes y avanzadas presentaciones así como su manera de evitar sistemáticamente la cultura popular simplificada en exceso que habitualmente tienta a los programadores inmaduros a perder el tiempo y hacer que sus proyectos fracasen. ara obtener más información visite Ayal Zylberman QualiTest, Israel Ayal Zylberman es un experto especialista de pruebas de software y uno de los fundadores del Grupo QualiTest. Lleva en el sector del testing de software desde 1995 testeando diversas disciplinas como sistemas militares, sistemas de facturación, SA, RT, NMS, conexión de redes y telefonía. Fue uno de los primeros en Israel en implementar herramientas de testing automatizadas y está reconocido como uno de los expertos más prestigiosos en este campo a escala mundial. Ayal ha participado en actividades de automatización de pruebas en más de 50 empresas. Durante su carrera profesional, ha publicado más de 10 artículos profesionales en todo el mundo y es un ponente muy solicitado en conferencias israelíes e internacionales. Salvador Folgado Bull, España Salvador Ignacio Folgado Bellido, es el director de aseguramiento de la calidad de software de Bull España S.A. con mas de 15 años de experiencia en tecnologías de información, y especializado en estudios de rendimiento y consultoría de aplicaciones. Certificado roject Management rofesional desde hace más de 9 años, Salvador Folgado tiene el Master de Ingeniería de Software de la Universidad olitécnica de Valencia. Los últimos años esta dedicado a crear, optimizar y sintetizar metodologías de testeo y optimización de procesos de calidad en el ciclo de vida del software, desarrollando proyectos para empresas en todas las fases del ciclo de desarrollo de software, aplicando y adaptando las mejores practicas del mercado en el aseguramiento de la calidad de software. Keynote: Cómo evaluar si la especificación de requisitos es suficientemente buena para el testing: el proceso de inspección ágil y la salida numérica Tom Gilb, fundador y director de diferentes disciplinas técnicas como la Inspección y la gestión de proyecto EVO, resume en esta conferencia cómo evaluar si la especificación de los requisitos es suficientemente buena para el testing. En concreto, se centrará en: * los estándares básicos para los requisitos de testing * la revisión ágil de 30 minutos para los requisitos: cómo medir la densidad de defectos de los requisitos * la noción de salida numérica: cuándo los requisitos son suficientemente buenos para la creación de pruebas * tratar con los escritores de requisitos despistados: cómo conseguir que escriban requisitos decentes onente: Tom Gilb Testing exploratorio automatizado La definición más conocida del testing exploratorio es de James Bach: El testing exploratorio es un proceso simultáneo de aprendizaje, diseño y ejecución de pruebas(1) El testing exploratorio automatizado es un método que sirve para automatizar el proceso de ejecución de pruebas mediante una herramienta que permite a los testers ahorrar dinero y ser más productivos durante la ejecución de las pruebas. Recientemente he tenido la ocasión de poner en práctica este enfoque con dos clientes importantes. En el primer caso, no existía ninguna automatización en el proyecto, por lo que utilizamos una herramienta de un tercero que permite registrar todas las acciones de un tester durante la ejecución de pruebas, tras lo cual se puede analizar el archivo de registro e incluso utilizarlo para una prueba de regresión posterior. Este método se llama Testing exploratorio automatizado pasivo (AET pasivo). En el segundo caso, se utilizó un enfoque KDT (testing dirigido por palabra clave) y utilizamos la infraestructura KDT para automatizar la ejecución de pruebas. Este método se llama Testing exploratorio automatizado activo (AET activo). La presentación describirá ambos métodos y presentará técnicas y herramientas utilizadas en la implementación de testing exploratorio automatizado. Se detallarán ejemplos de implementaciones reales de estas técnicas. (1) Exploratory Testing Explained by James Bach, v.1.3 4/16/03 onente: Ayal Zylberman Una visión practica del aseguramiento de la calidad de software La exposición realizará un resumen de la metodología de calidad y su aplicación práctica dirigida a proyectos tipo e implementada en cada fase de construcción del software (bien de modo lineal, espiral, o con métodos ágiles), introduciendo el concepto de certificación de aplicaciones como un análisis de riesgos de las mismas. No debemos olvidar que la calidad no es en si un fin, sino un medio cuyo objetivo es, conocer, dimensionar y evitar desastres en producción. Realizaremos consideraciones sobre las herramientas existentes en el mercado; éstas deben banalizarse y adaptarse a la idiosincrasia de la entidad y no viceversa: ello agilizará y flexibilizará el proceso de certificación. Se exploran algunas soluciones y herramientas existentes en el mercado, su adaptación y su aplicación práctica, en los análisis de calidad identificados. lantearemos Qué hacer, Cómo hacer, Quién y por Dónde iniciar una implantación de una oficina de calidad de software tanto en aquellas entidades que ya dispongan de iniciativas al respecto como en aquellas en las que no. Finalmente se mostrará el valor aportado por una oficina de calidad, considerando los resultados consolidados en las distintas fases de análisis considerados en la certificación de calidad, bajo un supuesto practico de certificación de aplicaciones. onente: Salvador Folgado 11 con traducción

12 Martin Knobloch OWAS Org, aises Bajos Martin Knobloch trabaja como Arquitecto de software en Sogeti Nederland B.V. Es fundador y presidente del equipo de trabajo roactive Security Strategy (ass). El equipo de trabajo se centra en la seguridad de la aplicación en todo el ciclo de vida de la aplicación. El equipo ass cuenta con toda la experiencia relacionada con el desarrollo de aplicaciones, desde el analista de información hasta la arquitectura, el diseño y los desarrolladores así como los testers y los administradores de la aplicación. En su trabajo diario, Martin es responsable de la formación en temas de seguridad en aplicaciones y la orientación e implementación de medidas de seguridad en aplicaciones para clientes. Martin es miembro de VIB.nl y OWAS.org. En OWAS, forma parte del Consejo de la división holandesa. Además, contribuye en varios proyectos como el Boot Camp de OWAS, el Speaker roject de OWAS y es director de proyecto del proyecto de formación de OWAS. Martin también es miembro del Comité de Educación Global de OWAS. Martin ha presentado diversas conferencias nacionales e internacionales: * aíses Bajos: SDN, Engineering World, * Noruega: ROOTs * OWAS AppSec en los aíses Bajos, Bélgica, Australia y los EE.UU. Seguridad en la aplicación: concienciación Qué es una aplicación segura? De qué tenemos que ser conscientes? En la primera parte de esta sesión interactiva se tratarán las causas de las aplicaciones de software inseguras. Después, se presentará el royecto de seguridad de aplicaciones web abiertas (Open Web Application roject, En esta parte, Martin explicará cuáles son los cuatro proyectos OWAS más importantes y cómo pueden ayudar a convertir las aplicaciones en seguras. Al final, después de una presentación de OWAS España, se hablará de los diez proyectos OWAS más importantes de 2007 y se demostrarán con las herramientas WebGoat y WebScarab de OWAS. onente: Martin Knobloch Siva Kannan Symantec Corporation, EE.UU. Siva Kannan tiene unos 10 años de experiencia en diversos ámbitos del desarrollo del software de producción. Actualmente es Director Senior de Ingeniería de roducto en la empresa Symantec. Tiene un MBA de la Marshall School of Business, University of Southern California, EE.UU., y un BS en ciencias informáticas de la Madras University, India. Siva ha trabajado como Director de Ingeniería de roducto en la empresa Symantec para productos Norton dirigidos al consumidor como Norton AntiVirus, Norton Internet Security y Norton 360, y como Director de programa y desarrollador de la Microsoft Java Virtual Machine en Microsoft. Ha recibido muchos elogios por su trabajo como desarrollador y director en las empresas Symantec y Microsoft y ha participado como ponente en la conferencia Cutting Edge 2008 que incluye público de Symantec de todo el mundo. También ha publicado un libro blanco sobre Cloud Computing and Security en el boletín de noticias de la dirección técnica de Symantec. El testing de software efectivo es fácil He desarrollado y testeado software durante más de 10 años y todavía veo gente que testea software para asegurarse de que las funciones del módulo encajan con la especificación funcional. Eso es solo un test funcional. Un testing eficaz, consistente en romper el software, es mucho más que eso. Se aparta del testing positivo y su objetivo es que el software falle. Utiliza la estrategia del testing negativo. De este modo se fuerza a los testers a pensar dónde se originan los errores/ defectos. Se debe tener en cuenta que hay una relación proporcional entre el aumento del número de errores detectados en una parte del software con la probabilidad de que existan errores no detectados. El testing positivo solo puede detectar los defectos del software parcialmente. Esta sesión muestra diferentes técnicas que ayudarán a los testers a descubrir un conjunto de defectos totalmente nuevo en el espectro de defectos. También ofrece una breve introducción para comprobar el nivel de seguridad de un software. onente: Siva Kannan 12 Claudia Badell UdelaR, Uruguay Desde el año 2006 es docente del Instituto de Computación de la Facultad de Ingeniería, Universidad de la República, Uruguay. Actualmente se desempeña como Test Leader. Se ha desempeñado como Coordinadora del equipo de Testing, donde sus actividades principales fueron, coordinación y planificación de las actividades de testing de los proyectos de la empresa aplicando SCRUM, capacitación al equipo de testing, técnicas de diseño de casos de prueba, como también, soporte y capacitación en la automatización de pruebas funcionales: Selenium RC, JUnit y Cruise Control. Investigó y trabajó en proyectos en el área de automatización de pruebas funcionales, como también trabajó en proyectos de pruebas funcionales manuales. Anteriormente desempeñó tareas como Tester durante dos años y medio en el Centro de Ensayos de Software, y fue analista de sistemas durante casi un año en UTE, empresa estatal. Testing y SCRUM: Caso de Estudio Hoy día, en una gran cantidad de proyectos de desarrollo de software se aplican procesos ágiles para su construcción. En estos procesos, la planificación de las pruebas cada vez se vuelve más crítica, ya que los tiempos son cortos, teniéndose que adaptar los equipos de testing a estos procesos. Dentro de los procesos ágiles se encuentra SCRUM. En esta presentación se muestra como se adaptó SCRUM para incorporar las actividades de testing al SCRUM team. Se incluyen las actividades llevadas a cabo por el equipo de testing como también ejemplos de las plantillas utilizadas para registrar la información en forma rápida y concisa. Esta experiencia se llevó a cabo con 8 proyectos que aplicaban SCRUM, los cuales estaban conformados en total por 18 desarrolladores, 10 testers y 2 SCRUM Master. Esta experiencia muestra que en los procesos ágiles también se puede documentar, diseñar casos de prueba, y a su vez, dar visibilidad del trabajo realizado por el equipo de testing a todos los actores. onente: Claudia Badell con traducción

13 José Ramón Martínez Salio Nextel Engineering, España Ingeniero Industrial por la Escuela Técnica Superior De Ingenieros Industriales de Madrid (UM). Especialidad AUTOMÁTICA. De 2006 a la actualidad trabaja en Nextel Engineering SL efectuando trabajos como: rogramador: royectos de desarrollo en VB.net, C#, C++ y Simulink (MathLab). Consultor de las herramientas de IBM Rational; implantación, consultaría y cursos de formación de estas herramientas. En colaboración con IBM. Entre 2004 y 2006 efectúo trabajos como: Responsable de calidad departamento de I+D de la consultora NEXTEL. Responsable de la calidad de los proyectos del departamento. Implantación de modelo de calidad basado en RU. Consecución de ISO royecto de implantación de CMMI en su nivel 3. Jefe de pruebas del departamento de I+D de la consultora NEXTEL. Dirección de un equipo de tres personas. Entre 1998 y 2004 trabajo en Meta 4 Spain. Realizo trabajos como ingeniero de pruebas (QA). Ha publicado los siguientes artículos: ROGRAMACIÓN ORIENTADA A LA CALIDAD: Dos artículos sobre calidad de software. ublicados en la revista SOLO ROGRAMADORES en los números de Mayo y Junio de Thirteen Steps to Bulletproofing your Automation Scripts : Articulo publicado en la revista Software Test & erformance, Octubre Tendencias y posibilidades del análisis estático y dinámico de código La ponencia muestra las tendencias y posibilidades del análisis estático y dinámico de código. Explora las diversas herramientas y técnicas existentes, desde las más conocidas hasta los últimos desarrollos universitarios de investigación. Se hace especial hincapié en temas como métricas (ISO 9126), estimación de defectos pendientes (mediante captura-recaptura y otros) y detección automática de defectos (mediante determinación de reglas internas, invariantes, rangos habituales y otros). onente: José Ramón Martínez Salio Sergio López IBM, España Sergio López es técnico de preventa de Software de IBM Rational. Actualmente desarrolla su carrera profesional en IBM Rational como especialista de Software de gestión de la calidad. Anteriormente ha trabajado en IBM como técnico especialista de desarrollo de aplicaciones web durante más de ocho años. Rational Quality Manager. Novedades y mejoras en la gestión de pruebas. IBM Rational Quality Manager es la solución de IBM para la gestión centralizada de las pruebas en un entorno colaborativo, basada en roles, enfocada a los objetivos del negocio y a equipos de todos los tamaños. En esta presentación se expondrán las novedades de la versión 2.0 tales como nuevas capacidades de reporting, integraciones, mayor usabilidad, gestión de permisos o pruebas basadas en riesgos. onente: Sergio López El modelo en V múltiple: todavía en plena forma? 13 André Verschelling SOGETI, aises Bajos André Verschelling tiene aproximadamente 15 años de experiencia como profesional en el ámbito de los sistemas empotrados. Durante este tiempo ha trabajado para diversas empresas en proyectos de desarrollo de sistemas como impresoras, sistemas de congresos y sistemas de transporte, entre otros. En el ámbito de estos proyectos ha desempeñado diversos cargos, como desarrollador de software, ingeniero de pruebas del sistema, integrador de sistemas, integración y pruebas como líder de equipo y mantenimiento como líder de equipo. En todos estos proyectos se ha centrado especialmente en la calidad y los métodos. Desde enero de 2006, André trabaja para Sogeti High Tech en los aíses Bajos. Actualmente trabaja como consultor de pruebas y líder de equipo para la gestión del ciclo de vida para un cliente que desarrolla dispositivos médicos. aralelamente a su trabajo, desarrolla e implementa la formación de colegas de Sogeti menos experimentados e imparte clases en el curso de Sogeti TEmb: Testing Embedded Systems. En 2002, el libro Testing Embedded Software significó todo un logro en la búsqueda de un enfoque sobre las pruebas en los sistemas empotrados. El libro presentaba el modelo en V múltiple y distinguía claramente las fases especiales en el desarrollo de sistemas empotrados y las pruebas. Sin embargo, la mayoría de empresas no reconocen directamente el modelo en V múltiple. Además, el modelo en V, bastante anticuado, parece estar en retroceso ante los nuevos modelos de desarrollo ágil. ero, es esto lo correcto? Si me baso en mi experiencia en el desarrollo de sistemas incrustados y pruebas, he aprendido que la mayoría de empresas no reconocen el modelo en V múltiple porque se centran en el propio producto, del que dicen que es verdaderamente único. or lo tanto, el enfoque del desarrollo y las pruebas también se considera que es único. Sin embargo, la realidad es que, pese a todos los productos únicos, la mayoría de empresas se organizan según un roceso de creación de producto para crearlos. En oposición a los productos únicos, este roceso es un enfoque genérico muy extendido y constituye el primer paso hacia un enfoque de pruebas genérico. En esta conferencia, llevaré a cabo este paso del roceso hacia un enfoque de pruebas genérico, presentando de nuevo el modelo en V múltiple, y trataré de encontrar las relaciones entre ambos. Demostraré cómo el modelo en V múltiple se puede correlacionar con los equipos de proyecto. Esto incluye el uso de métodos de desarrollo ágil y la selección de ciertas técnicas de pruebas en la programación de modelo en V múltiple. or supuesto, ejemplificaré mis comentarios con experiencias en el uso del enfoque en el desarrollo y pruebas de los sistemas empotrados. onente: André Verschelling con traducción

14 Gestión efectiva de la calidad de un producto software Antonio Sepúlveda Carrero INTECO, España Licenciado en Ciencias Físicas, especialidad en Física Industrial y Automática, con seis años de experiencia en proyectos de desarrollo y mantenimiento de software. Comenzó su carrera profesional trabajando para la Consultora Tecnológica CORITEL B..M en proyectos de desarrollo en el sector banca y de seguros, para clientes nacionales e internacionales. Tras este periodo pasó a formar parte de la compañía ROFIT (Sopra Group) donde intervino en proyectos de desarrollo y mantenimiento de aplicaciones informáticas en el entorno bancario. Antes de su paso a la Administración ública, trabajó para la Consultora CAGEMINI en proyectos de consultoría y desarrollo software para clientes del sector bancario. Desde octubre de 2007 trabaja en el Instituto Nacional de Tecnologías de la Comunicación (INTECO) como Responsable Técnico del área de Calidad del Software. Conseguir la satisfacción del cliente es mucho más que conseguir entregar un producto sin errores. Es necesario un proceso que asegure la calidad a través de todo el ciclo de vida de desarrollo. Al final de cada fase debería comprobarse que el trabajo realizado hasta ese momento cumple con todos los objetivos previstos. Este tipo de comprobaciones a lo largo del ciclo de vida incluyen dos actividades: la verificación y la validación. Estas actividades tienen un coste, por ello, es importante optimizar las pruebas de software priorizando qué se va a probar y qué partes se van a automatizar. Llevar a cabo una estrategia de pruebas desaconsejable lleva al fracaso. ara poder evaluar el éxito de una estrategia o proceso de pruebas es necesario implementar métricas de calidad que ayuden a la toma de decisiones. INTECO, en su labor de contribuir al desarrollo de la Sociedad de la Información, ofrece un conjunto de servicios desarrollados desde su Laboratorio Nacional de Calidad del Software que orientan a las empresas en la gestión de la calidad del software. onente: Antonio Sepúlveda Carrero 14 José Murillo Microsoft, España José Murillo se incorporó a Microsoft España en 2002 como Consultor de Desarrollo de Aplicaciones para dar apoyo a los fabricantes de software independiente (ISV) del país. Al cabo de tres años, se incorporó al equipo de Divulgación de desarrollos y plataformas, donde dirigió la estrategia de los ISV. Durante este período se encargó de adoptar las tecnologías más modernas utilizadas por estos ISV. También definió y puso en marcha el programa de empresas de nueva creación en España. En 2008, se unió al equipo de ventas de Microsoft Development Tools, donde es responsable de ventas de Microsoft Application Lifecycle Management (ALM), Visual Studio y Expression a los principales clientes y socios de Microsoft. Antes de incorporarse a Microsoft, trabajó para Telvent (Grupo Abengoa) durante dos años, en los que dirigió el desarrollo de un producto SCADA nacional. También trabajó para Energy Workspace en Houston, una empresa de nueva creación durante la burbuja de Internet en Anteriormente, fue el propietario de una empresa de desarrollo de software. Cuenta con una amplia experiencia en el desarrollo de software y en herramientas ALM y ha sido ponente en numerosas conferencias y eventos del sector. Calidad del Desarrollo Software con Visual Studio, Microsoft Test y Lab Management En esta sesión ofreceremos una visión de las herramientas actuales y futuras que Microsoft pone a disposición de los equipos de Desarrollo de Software para la gestión de la calidad de los mismos. Amparados bajo el paragua de Team Foundation Server, el gestor ALM de Microsoft, los diferentes roles técnicos y no técnicos colaboran sin fricciones en la identificación y resolución de incidentes. Team Foundation Server asegura la relación y trazabilidad entre los diferentes elementos del proyecto (requisitos, casos de uso, tareas, código, incidentes, etc.) ofreciendo métricas en tiempo real sobre la evolución de la calidad del software y siempre asegurando el cumplimiento de la metodología de desarrollo seleccionada para el proyecto en cuestión. Las diferentes versiones actuales de Visual Studio (Team Architecture, Team Test y Team Development) ya ofrecen hace tiempo funcionalidad específica para los probadores técnicos en sus diferentes roles. Las Directivas de Arquitectura en la versión Team Architecture permiten al Arquitecto de Software y de Sistemas la definición de restricciones y políticas en la arquitectura lógica y física del software, impidiendo a los desarrolladores la codificación en contra de las mismas. Las herramientas para el diseño y la ejecución automatizada de ruebas Unitarias, el Análisis de Cobertura de Código así como pruebas sobre de Código Fuente facilita a los desarrolladores en la versión Team Development la incorporación de buenas prácticas en sus desarrollo así como el aseguramiento de la calidad del código generado. or último, las funcionalidades en la versión Team Test permiten el diseño y codificación de ruebas de Interfaz Automatizadas para aplicaciones ricas o Web, así como la ejecución de ruebas de Carga contra entornos de pruebas o preproducción. Con la inminente aparición de la nueva versión 2010 de Visual Studio, Microsoft lanzarán al mercado herramientas para probadores generalistas o no técnicos, destinadas a asegurar la calidad funcional de las aplicaciones en diferentes entornos de forma automática, y que vienen a completar la oferta ya existente de pruebas cubriendo así todo el ciclo de vida al completo así como a todos los roles involucrados en el desarrollo de software. Se introducen en Visual Studio Team System (como se conoce a la suite completa de productos de desarrollo) productos específicos para estos probadores funcionales como son Microsoft Test y Microsoft Lab Management. Microsoft Test permite el diseño de un plan de pruebas ligado a los requisitos y casos de uso del producto, la ejecución manual, semiautomática o automática del plan de prueba y el seguimiento de los defectos del producto. La relación entre el probador funcional y el desarrollador es muy estrecha a través de las nuevas herramientas, ya que permiten al probador dar de alta nuevos incidentes con toda la información necesaria adjunta de forma transparente para que el desarrollador pueda completar su trabajo evitando los incidentes no reproducibles y su elevado coste. De esta forma el desarrollador dispone en cada incidente de acceso a una foto del entorno congelado donde el probador reprodujo el incidente, que sumada a nueva funcionalidad de Visual Studio como Historical Debugging hacen ya de los incidentes no reproducibles un mito. Otras funcionalidades avanzadas como el Análisis de Impacto y el Fast Forward (reproducción automática de pruebas) permitirán un ahorro de costes considerable en los equipos de pruebas. or último, Microsoft Lab Management ofrece a los probadores funcionales un producto donde poder gestionar entornos virtuales de pruebas de forma extremadamente sencilla. Basado en máquinas virtuales y la tecnología Hyper-V, permite definir y configurar despliegues automáticos hacia diferentes entornos con múltiples configuraciones, así como la ejecución automatizada de pruebas funcionales en los mismos. La ejecución de ruebas de Regresión en diferentes configuraciones nunca habrá sido tan sencilla como hasta ahora. onente: José Murillo con traducción

15 José Aracil Testhouse, España José Aracil es Experto en Soluciones relacionadas con la calidad del software en Testhouse España. Durante sus primeros años en el entorno empresarial, José trabajó para el grupo estadounidense AD donde tuvo la oportunidad de profundizar sus conocimientos en áreas relacionadas con el desarrollo de software sobre tecnologías Oracle, así como la seguridad empresarial. Durante los últimos ocho años, ha realizado numerosos proyectos relacionados con la calidad del software como consultor de Testhouse en Reino Unido, Suiza y Alemania. La experiencia obtenida trabajando en empresas, donde la calidad del software tiene un papel fundamental dentro del ciclo de desarrollo, hace de José la persona idónea para analizar las necesidades de los clientes de Testhouse y aportar las mejores soluciones. En el área de pruebas no funcionales, se ha especializado en la detección de problemas de rendimiento y seguridad en sistemas multicapa, donde un buen entendimiento del entorno es clave. Jose ha trabajado como Test Manager gestionando proyectos funcionales y no funcionales en modalidades near-shore (Testhouse UK) y off-shore (Testhouse India). A nivel personal sus intereses se centran en los nuevos medios de comunicación web, la optimización de sistemas para entornos móviles y la fotografía. Leticia Zárate Casanova olar Consultores, España Leticia Zárate Casanova se incorpora a olar Consultores en 2001 para la realización de pruebas funcionales sobre el desarrollo de la herramienta itestman. osteriormente participa en el diseño y ejecución de pruebas de distintas aplicaciones como NSF (Nuevo sistema de Facturación de Teléfonica Móviles), SCM (Sistema de contratación Multiservicio de Teléfónica de España) y distintos proyectos de Verificación y Validación Independiente de Sistemas de Navegación Aérea. A partir de 2005 se centra en las labores de consultoría en la aplicación de la herramienta itestman a proyectos de pruebas de empresas como CAM (Caja de Ahorros del Mediterráneo), MAS-UAC New FDS (Eurocontrol), Mitcham-Frankston (SICE-DRAGADOS), así como labores de consultoría para el aseguramiento de la calidad. Desde 2007 es jefe de proyecto de itestman, labor que desempeña en la actualidad. ruebas de rendimiento, carga, estress... hablamos todos de lo mismo? Quien no ha escuchado alguna vez la frase: Quiero que rompas el sistema!. No parece una frase muy lógica, excepto en el contexto de las pruebas de rendimiento. Cuando un cliente realiza esta petición suele tener en mente las pruebas de estrés, o mejor dicho, lo que el cree que son las pruebas de estrés. Durante esta ponencia se explicaran conceptos comúnmente intercambiados, como son las pruebas de rendimiento, pruebas de carga y pruebas de estrés. Se profundizara de forma teórica en estos elementos, y mas tarde de forma practica, mostrando el proceso a seguir durante un proyecto de pruebas de rendimiento, desde los pre-requisitos, hasta los entregables, pasando por las ejecuciones de pruebas y análisis. ara terminar la sesión, se repasaran algunos mitos existentes en torno a esta practica. onente: José Aracil Realización de un proyecto de pruebas multiemplazamiento con herramientas basadas en WEB Cada vez es más común en los proyectos de pruebas la diversidad de emplazamientos en las distintas actividades y fases del proyecto (fábrica, integración, implantación, pruebas, producción). Esta situación ocasiona diferentes repositorios de información, y por lo tanto, dificultad a la hora de conocer el estado de las actividades del proyecto. La solución para solventar esta situación es centralizar la información y proporcionar accesibilidad via web a todo el personal involucrado, de modo que se permita conocer en tiempo real el estado de los elementos del proyecto: grado de cumplimiento de requisitos, cobertura de las pruebas diseñadas, resultados, problemas detectados... Características de un proyecto de pruebas de un sistema de control de tráfico aéreo Los proyectos de prueba de sistemas de control de tráfico aéreo se caracterizan por ser sistemas críticos, con fuertes criterios de aceptación por parte del cliente final y normativas de calidad exigentes. arte de la complejidad de probar estos sistemas reside en que generalmente es necesario ser capaces de validar simultáneamente distintas versiones de software, que cumplen diferentes versiones de requisitos. Además hay equipos de prueba en más de un emplazamiento. A lo largo de la conferencia veremos ejemplos reales de cómo se planifican y llevan a cabo estos proyectos de IV&V, cubriendo todas las fases: gestión de requisitos, diseño de pruebas, ejecución de pruebas y gestión de anomalías. Se podrá ver la utilización de la herramienta itestman, 100% web. Se hará especial hincapié en la obtención de métricas en los proyectos y en la posibilidad de acceder a través de Internet a la información y explotarla desde otras aplicaciones (por ejemplo, MS Excel o MS roject). onente: Leticia Zárate Casanova 15 Teodora Bozheva European Software Institute, España Teodora Bozheva es Senior Consultant en el European Software Institute (ESI). Trabaja con YMEs en diferentes países dándoles soporte a la implementación de CMMI ML2 y ML3. Teodora es instructora autorizada por el SEI a impartir los cursos Introduction to CMMI y Acquisition Supplement for CMMI-DEV. Está certificada como Six Sigma Black Belt. ruebas efectivas mediante Six Sigma Lean Six Sigma es una metodología que suele asociarse con las industrias de manufactura, métodos estadísticos difíciles y niveles de alta madurez del modelo CMMI. Todavía hay poca experiencia con Lean Sigma en el dominio de software y TI. Esta presentación va a introducir unos conceptos básicos de Lean Six Sigma y va a presentar un caso práctico de la aplicación de la metodología en el desarrollo de productos compuestos por componentes software, hardware y mecánica con el objetivo de o Aumentar la eficacia del proceso de pruebas o Reducir el numero de los defectos en los productos finales o Aumentar la satisfacción de los clientes. Se van a presentar las actividades que se han realizado en el proyecto desde la definición del problema hasta la implantación de su solución en la empresa tal y como los beneficios obtenidos por la organización como resultado del proyecto. Se explicarán en más detalle las técnicas six sigma que se han visto más útiles en el proyecto. También se presentarán las lecciones aprendidas por el equipo del proyecto a lo largo de su ejecución. onente: Teodora Bozheva con traducción

16 16 Leo Van der Aalst SOGETI, aises Bajos Tras una trayectoria tradicional por las TI (desde programador hasta gestor de proyectos) Leo van der Aalst se ha especializado desde 1990 en el ámbito del testing, en el que ha desempeñado cargos como gerente de testing, consejero de testing, director de investigación y desarrollo y director de operaciones. Como director de desarrollo del negocio es coautor de los libros de TMap NEXT y TMap NEXT BDTM y ha desarrollado entre otros servicios en la implementación de organizaciones de testing, la externalización de pruebas y la gobernabilidad del testing. Leo también ha diseñado los ejercicios del EXIN para el TMap NEXT Foundation así como para el examen Avanzado y ofrece formación preparatoria para estos exámenes. Además, Leo trabaja como profesor adjunto de calidad y testing de software en la comunidad Fontys Hogescholen. Leo ha aplicado sus conocimientos y su experiencia en el campo de la gestión de pruebas y proyectos durante diversos proyectos internacionales y trayectorias de consultoría (en los EE.UU., Alemania, Dinamarca y Austria). Además de todo esto, Leo es un profesor muy solicitado en la formación para testing y un ponente habitual en conferencias nacionales e internacionales (entre otros, STARWEST y NSQC (ambas en los EE.UU.), EUROSTAR (Europa), Test Congress y Test Expo (ambas en el Reino Unido), Test2008 (India), Quality Week Europe (Bélgica), ICSTEST y TAV (ambas en Alemania) y QA&TEST (España)). También es autor de varios artículos (entre otros, sobre cómo calcular el valor añadido del testing, el testing basado en los riesgos y las ventajas de un centro de servicio de testing). Miguel Ángel Rial H, España Miguel Ángel Rial, es Ingeniero Superior de Telecomunicaciones por la Universidad de Vigo y ha desarrollado su carrera profesional durante estos 10 años en el ámbito del software de gestión, más específicamente en el área de la calidad de las aplicaciones. Ha desempeñado su labor en diferentes compañías estando esta siempre asociada al desarrollo de negocio, mencionamos algunas de las compañías en las que ha trabajado: Telefónica I+D, Telefónica Móviles y Mercury. Tras la adquisición de Mercury por H Miguel Ángel continua su labor en el área de calidad como responsable de preventa de calidad del área centro de España. Augusto Sagrario érez SOGETI, España Augusto Sagrario érez es Consultor Senior de rocesos y Testing en SOGETI. Su carrera profesional se ha desarrollado siempre dentro del mundo de software, primero en la parte de desarrollo como desarrollador, jefe de proyecto y jefe de desarrollo y los últimos diez años dentro del mundo del aseguramiento de la calidad del software como consultor Senior de procesos, SQA y Testing. Miguel Angel Cervera Roig GFI, España Miguel Angel Cervera cuenta con más de diez años de experiencia en TI, es Gerente del área de consultoría SQA de GFI Informática liderando un equipo especializado en testing y aseguramiento de la calidad del software de más de 70 consultores tanto en actividades de preventa, como de ejecución y postventa de servicios. Entre sus principales responsabilidades recae la definición y divulgación de la oferta, el plan estratégico del área y la relación operativa con fabricantes de software y clientes. Miguel Angel Cervera es socio fundador del SSTQB (Comité Español de Testing) liderando el grupo de procesos y colaborando activamente en la matriz internacional ISTQB. Fecha: 29/10/2009 Ahorro de tiempo tremendo con la técnica de pruebas adecuada Resumen Seleccionar una técnica de pruebas apropiada resulta difícil. En los libros e Internet se pueden encontrar muchas técnicas, algunas muy conocidas y otras que han creado los propios testers. Además del objeto que se tiene que testear y la intensidad de pruebas seleccionada, la elección depende en gran medida de aspectos como la base de las pruebas, los conocimientos y las habilidades de los testers y la intensidad del trabajo. Esta presentación le ofrece herramientas para seleccionar una o más técnicas apropiadas teniendo en cuenta los aspectos mencionados anteriormente; podrá comprobar cómo así puede ahorrar una cantidad de tiempo y dinero enorme a la hora de crear casos de testing. Contexto A menudo, los clientes e incluso los testers se quejan de que el uso de técnicas de diseño de testing es una tarea difícil y que exige mucho tiempo. Si pudieran librarse, preferirían no utilizar ninguna técnica. Es una lástima, porque estas técnicas representan la única manera de llevar a cabo la estrategia de testing acordada de una manera demostrable. A menudo, cuando se afirma que el uso de técnicas de diseño de testing exige mucho tiempo, se olvida que es posible que las técnicas se utilicen incorrectamente. El objetivo no es que el tester diseñe todos los casos de testing posibles, sino más bien que seleccione una técnica específica en relación a la estrategia del testing seleccionada y que intente así conseguir la probabilidad de descubrimiento de defectos más alta posible con el mínimo de casos de testing posible. En la práctica, nos encontramos que los testers a menudo se inclinan por la opción equivocada. El resultado implica el diseño de una cantidad de casos de testing excesiva. Esta es una causa importante que invita a pensar que el uso de técnicas exige mucho tiempo. onente: Leo Van der Aalst Fecha: 29/10/2009 Agile con Quality Center de H La evolución que se ha producido en los últimos años en el mundo de TI ha transformado a las organizaciones/aplicaciones monolíticas en entornos distribuidos que soportan aplicaciones compuestas, esto ha llevado pareja la aparición de metodologías de desarrollo ágiles. La flexibilidad inherente de las metodologías Agile tiene un claro impacto en la fase de pruebas que debe ser redefinida para adaptarse a los cambios constantes en el proceso de desarrollo. La definición, realización y automatización del proceso de pruebas en el marco de Agile requiere de una planificación precisa de los procesos y las soluciones que lo soportan. Soluciones que deben facilitar y reforzar el trabajo en este entorno como es el caso de la plataforma H Quality Center. onente: Miguel Ángel Rial Fecha: 29/10/2009 Coste de la calidad y de la no Calidad Todas las organizaciones se realizan la misma pregunta: Cómo podemos bajar los costes del software? Básicamente, los costes del software se pueden agrupar en dos grandes apartados: * Directos: costes del roceso de desarrollo (ersonal, instalaciones, herramientas, etc.). * Indirectos, costes que nos origina la falta de calidad del producto durante la elaboración y mantenimiento del mismo, es decir, costes de la no calidad. Normalmente todas las organizaciones se fijan en los costes directos y ponen en marcha acciones encaminadas a reducirlos (CMMI, Frameworks, etc.) y se olvidan de los indirectos, alegando que son difíciles de cuantificar. Que no podamos cuantificar exactamente el valor de una elemento o proceso, no es obstáculo para que no podamos acotarlo y por lo tanto controlarlo. Mediante la acotación y control de estos costes indirectos se sientan las bases para la reducción de los costes. Ahora bien como podemos reducir los costes de la no calidad?. ara poder mejorar algo lo primero que debemos hacer es medir. Una buena base de partida son los modelos de cálculo del coste de la calidad, los cuales nos ayudan a medir y controlar dichos costes. onente: Augusto Sagrario érez Fecha: 29/10/2009 La calidad objetiva: Métricas e indicadores Las métricas e indicadores de la calidad del producto representan la herramienta definitiva para los responsables de calidad del software que persiguen una transmisión objetiva, medible, repetible, comparable y homogénea del resultado de su trabajo. Implantar esta disciplina en una organización facilita el objetivo soñado por todos nosotros: la involucración de la dirección de TIC en la toma de decisiones basada en el resultado de las V&VI. A lo largo de esta presentación revisaremos algunos de los principales modelos de métricas e indicadores, consejos y buenas prácticas en la implantación y explotación de un modelo de métricas en una organización, experiencias y otros factores de éxito de esta disciplina. onente: Miguel Angel Cervera Roig con traducción

17 Fecha: 29/10/2009 Modelo SOA TMA Antonio Luque SOGETI, España Actualmente Antonio Consultor de calidad de Software en Sogeti y ha desarrollado su actividad profesional en distintos proyectos de Consultoría en implantación de modelos de calidad de software en clientes como Cámara Oficial de Comercio e Industria de Madrid, Correos y Metro de Madrid. Formador y Consultor en metodología de desarrollo y procesos de calidad para proyectos internos de Accenture. TMap SOA Model consiste en tres capas: Generic Test Agreements (GTA), Business-driven Test Management (BDTM) y Tool box. Los GTA son similares a un Master Test lan. ara prevenir que en cada release se tengan que replantear el qué y cómo probar, se documentan dichos planteamientos en los GTA. BDTM se ha adaptado para las pruebas de SOA y hace posible la reducción de riesgos en compensación con el dinero invertido, el tiempo y los resultados obtenidos (los cuatro aspectos de IT Governance). También se define dos nuevos niveles de pruebas: las pruebas de servicio y las de integración de servicios. Los tres componentes principales de la Tool box son: 1. La matriz de aceptación. La matriz de aceptación indica quiénes son los responsables de aceptar cada una de las partes de la arquitectura. 2. El registro de servicios. En el registro de servicios se almacena, por servicio, los resultados de los análisis de riesgos de producto, la estrategia de pruebas y cualquier otro testware. 3. El SOA Test Harness. Un Test Harness es una herramienta de pruebas específica que permite probar un servicio de manera aislada, fuera de la orquestación de servicios a la que pertenece. onente: Antonio Luque Davor Crnomat Testway, Suecia Davor Crnomat tiene una larga experiencia en el desarrollo y testing de software. Tras empezar como desarrollador de software, Davor descubrió pronto la importancia de un testing estructurado. Esto le animó a iniciar una carrera dentro del testing. Davor trabaja principalmente como especialista en automatización de pruebas y gerente de pruebas. Su experiencia en la automatización de pruebas abarca las pruebas unitarias, la evaluación de herramientas, el uso combinado de herramientas de automatización de alto nivel y de código de bajo nivel. Davor ha trabajado principalmente como gerente de pruebas en proyectos tradicionales pero hace algún tiempo descubrió los proyectos ágiles y el testing ágil, que percibió como ráfagas de aire fresco. Una manera de testear rápida y sencilla: eso es lo que más le gusta a Davor. En su presentación, Davor hablará sobre sus experiencias en un proyecto ágil donde todo el testing fue realizado por desarrolladores. Davor tiene los títulos ISEB ractitioner y Scrum Master. Fecha: 29/10/2009 Blancanieves y los siete enanitos: Gerente de pruebas en un equipo ágil Esta es una historia sobre un tester y siete desarrolladores en un equipo Scrum. Realmente me sentía como Blancanieves en mis primeros días del proyecto: un gerente de pruebas sin ningún tester en el equipo. Solamente había siete desarrolladores. Tengo que hacer todas las tareas de la casa mientras los otros trabajan en la mina? Tengo que hacer todo el testing manual solo? Estas fueron algunas de las preguntas que me pasaron por la cabeza. Era obvio que todos teníamos que participar en el testing para hacerlo bien. ero, cómo podía convencer a los desarrolladores para que hicieran testing manual? No me gusta generalizar, pero me vi acosado por ciertos prejuicios, como: A los desarrolladores no les gusta la documentación o A los desarrolladores no les gusta el testing. Y a la gente le gusta pensar que donde hay humo, hay fuego. Así que mi objetivo era que solamente hubiera la documentación de pruebas estrictamente necesaria y hacer que los desarrolladores disfrutaran con el testing. En esta presentación les explicaré la historia de mis fantásticos compañeros desarrolladores y cómo aprendieron a disfrutar, incluso a amar el testing. Estos tipos han roto algunos mitos sobre los desarrolladores y han demostrado que pueden hacer testing perfectamente. onente: Davor Crnomat 17 Jan Fish hilips, EE.UU Jan Fish cuenta con más de 34 años de experiencia en el testing, sistemas de software, mejora de procesos y gestión de cambios para organizaciones de todos los tamaños en los sectores financiero e informático. Actualmente trabaja como gerente de pruebas y mejora de procesos en hilips Lifeline ( com) y ha dirigido un equipo de ingenieros de pruebas desde un estado sin procesos definidos hasta alcanzar un CMMI de nivel 4 en menos de tres años. Jan ha colaborado con equipos de proyecto para identificar e implementar mejoras de procesos que van desde la mejora de la trazabilidad en la implementación de revisiones de código en parejas hasta la ejecución de la comprobación del estado de preparación de la producción durante el proceso de aceptación del sistema (así se reducen las semanas en los cronogramas del proyecto). Jan Fish es defensora de un estado del producto transparente y preciso desde el punto de vista de las pruebas, así como de la colaboración con los equipos para recomendar los pasos que se deben seguir según los objetivos del momento. Fecha: 29/10/2009 Cómo medir la calidad en la entrada, no solo en la salida or lo general, las organizaciones evalúan la calidad del código tras el lanzamiento de la producción y se recogen mediciones de las pruebas durante su ejecución, pero no se comunican hasta el final del proyecto. or qué no se evalúa la calidad en la entrada en pruebas? Las revisiones de código ofrecen una indicación aproximada de la calidad y los datos de trazabilidad pueden evidenciar lagunas en la documentación y los casos de pruebas. Sin embargo, los verdaderos indicadores están en otro sitio. Con la medición de la cantidad de casos aprobados y fallidos y el cálculo del índice de fallos, se pueden anticipar tanto los fallos como la cantidad de ejecuciones de pruebas que se necesitan cada día. Esto permite ajustar los recursos, los cronogramas y el nivel de esfuerzo día a día o semana a semana. A continuación se muestra un método para medir la calidad en la entrada en pruebas mediante un sencillo conjunto de mediciones de cinco minutos al día. Utilizamos estos índices de fallos en múltiples puntos de decisión: Índice de fallos identificados frente a índice de fallos reales Criterios de suspensión Validación del cambio de proceso Acuerdos de contrato con proveedores Análisis de tendencias onente: Jan Fish con traducción

18 18 Igor Gershovich Connected Testing, EE.UU Igor Gershovich es el presidente y consultor director de Connected Testing, Inc., Denver, EE.UU., un desarrollador de soluciones de última generación para la automatización de pruebas. Igor ha trabajado los últimos 10 años en el sector de la alta tecnología, centrándose especialmente en la automatización de pruebas de software y llevando a cabo testings para las industrias aerospacial, de telecomunicaciones, de las finanzas y de la medicina. Igor ha desarrollado una estrategia de automatización de testing dirigido por palabras clave llamada SME-Centric Test Automation Framework. Igor es un ponente habitual tanto en grupos profesionales como en conferencias nacionales e internacionales. Stéphane Ayache Steria, España Stéphane Ayache es el Director para Europa de la Agencia Global de Testing del Grupo Steria. Desde el año 2000 Mr. Ayache ha venido desarrollando toda su carrera en el mundo de las pruebas, primero liderando el lanzamiento de la oferta de Testing del Grupo Steria en Francia (Testing&Quality Assurance), más adelante (en 2001) siendo el responsable del primer departamento dedicado exclusivamente a tareas de Testing en Francia, y desde el año 2006 como responsable de toda la actividad de Testing del Grupo Steria en Europa. Xavier Escudero Sabadell Generalitat de Catalunya, España Xavier Escudero es responsable de Calidad en el Desarrollo de Sistemas de Información para el CTTI (Centro de Telecomunicaciones y Tecnologías de la Información), empresa pública que planifica, dirige y controla los sistemas de información y telecomunicaciones de la Generalitat de Catalunya. Desde el 2007 se ha dedicado a la definición de procesos y estándares en calidad de las pruebas. En la actualidad está liderando un grupo independiente de aseguramiento de la calidad y pruebas. Xavier Escudero forma parte del Comité de Testing Español, organización sin ánimo de lucro que forma parte de la internacionalmente reconocida ISTQB - International Software Testing Qualifications Board. Jeff Johnson UI Wizards, EE.UU Consultor Director Yale University B.A., Stanford University h.d. Jeff Johnson cuenta con más de 28 años de experiencia en el sector informático, donde ha diseñado, implementado, evaluado y testeado interfaces de usuario en Cromemco, Xerox, US West, Hewlett-ackard y Sun Microsystems antes de convertirse en consultor. Fecha: 29/10/2009 Automatización de pruebas - Hablemos de negocios Es bien sabido que más del 60% de los proyectos de automatización de pruebas fracasan debido a expectativas poco realistas y a la falta de planificación. Esta presentación derriba los mitos que rodean la automatización de pruebas y lo que se necesita realmente para implementar eficazmente un testing automatizado rentable. Describe los costes de la automatización de pruebas y sus ventajas, además de los métodos para determinar el retorno de la inversión (ROI) de la automatización de pruebas. Esta presentación le ayudará a diseñar el entorno de trabajo que mejor encaje con su proyecto y cómo mejorar el ROI de la automatización. onente: Igor Gershovich Fecha: 29/10/2009 Cómo ayudamos a nuestros clientes a industrializar los procesos de pruebas Sólo con el uso de herramientas (tecnología) no se consigue mejorar la calidad de los procesos de prueba y, en definitiva, de todo el proceso de desarrollo. La clave está en una correcta combinación de los 3 ejes clave: herramientas, las mejores del mercado, personas, un equipo ampliamente experimentado y dedicado de pleno a la tarea de pruebas, y una correcta metodología. TestToMarket, la metodología de Steria para las pruebas de aplicaciones, está derivada de la propia experiencia de Steria en clientes, y es la clave para la industrialización de los procesos de pruebas en las organizaciones. La industrialización de los procesos de prueba, en base a una metodología de reconocido éxito, permite acceder a capacidades de alta cualificación y a herramientas de primer nivel. onente: Stéphane Ayache Fecha: 29/10/2009 Implantación de un Centro de Calidad y Testing Los sistemas de información son componentes críticos para nuestra organización y sus procesos (dirigidos al ciudadano, tributos, salud, justicia, etc.). Ahora bien, algunos proyectos se están ejecutando fuera de presupuesto y tiempo, y suelen aparecer un gran conjunto de defectos durante su operación, cuando ya son visibles a los usuarios finales. Desde el CTTI (Centro de Telecomunicaciones y Tecnologías de la Información de la Generalitat de Catalunya), se está implantando un Centro de Calidad y ruebas que permita ayudar a garantizar la calidad de las aplicaciones y sistemas de información de la Generalitat de Catalunya, tanto mediante actuaciones continuadas desde el principio de los proyectos, como en la realización de verificaciones puntuales de determinadas aplicaciones. Objetivos de la ponencia: * Motivación de la implantación del centro de calidad y pruebas o Causas y problemáticas de la mala calidad. roblemáticas genéricas y específicas. o Costes de la mala calidad o A que necesidad respondemos * Objetivos del centro de calidad y pruebas. Líneas de actividad. * Implantación del centro. * Estimación del coste de pruebas en los proyectos. * Definición de la estrategia de pruebas. * Roadmap del centro. * Experiencias y mejores prácticas. * Conclusiones onente: Xavier Escudero Sabadell Fecha: 29/10/2009 Keynote: El valor empresarial de la usabilidad Esta conferencia explica en términos empresariales por qué es importante para las organizaciones de desarrollo de software invertir esfuerzos para conseguir productos de alta usabilidad. Describe cómo la inversión en usabilidad puede: * mejorar la satisfacción del cliente * reducir el coste de ventas y soporte * aumentar el retorno de la inversión (ROI) * reducir el tiempo para alcanzar la rentabilidad y * minimizar el riesgo empresarial Describe cuándo y cuánto se debe invertir en usabilidad. onente: Jeff Johnson con traducción

19 Fecha: 29/10/2009 Requisitos y ruebas. Un modelo eficiente para gestionar las dependencias José Manuel Muñoz Visure, España José Manuel Muñoz es licenciado en ingeniería informática por la Universidad ontificia Comillas de Madrid. Mientras ejercía como profesor en la misma entró a formar parte del equipo de desarrollo de IRQA en TC SI. Tras 4 años en desarrollo en los que toma contacto con diversas técnicas de ingeniería de software y calidad pasa a formar parte del equipo de consultoría y negocio realizando diversas labores relacionadas con los requisitos y la ingeniería del software como consultorías, formación o pre-venta. Actualmente ejerce como consultor de IRQA en Visure Solutions. Que las pruebas son una parte vital en el ciclo de vida de un proyecto es algo obvio. Sin embargo, no son suficientes para asegurar la calidad de un proyecto. odemos crear el sistema más robusto y más estable para descubrir demasiado tarde que hemos desarrollado algo que no era lo que el cliente necesitaba o no hemos resuelto su problema de la manera más satisfactoria. Los requisitos juegan un papel fundamental a lo largo del ciclo de vida y del mantenimiento del proyecto y sin ellos no sabemos que estamos probando, como probarlo o si será o finalmente aceptado. Es por todo esto que los requisitos y su trazabilidad con las pruebas juegan un papel fundamental en el incremento de la calidad de un producto, en la reducción de costes y time to market y en la mejora de la gestión de riesgos y del propio proyecto. Contar con una herramienta que nos permita recoger conjuntamente requisitos, pruebas y las trazas entre ellos será una tremenda ayuda al facilitarnos enormemente las tareas de análisis de impacto del cambio (sobre requisitos y pruebas), de análisis de cobertura de pruebas, generación de informes, etc. más aun, si dicha herramienta permite realizar análisis de trazabilidad indirecta (esto es, de elementos no relacionados directamente) o nos ofrece ayudas para reutilizar entre proyectos esta información. Nicole Zanetti Beacon16, EE.UU. Nicole Zanetti es una experta Ingeniera de control de calidad con más de 10 años de experiencia. Ha trabajado en entornos que abarcan todos los paradigmas de la gestión de proyectos, desde el modelo en cascada al ágil. Ha defendido la necesidad de que el QA esté implicado en cada etapa del diseño y del desarrollo. Actualmente, Nicole es la ingeniera de QA experta para Beacon 16, una consultoría de tecnología de la información para el sector sanitario que ha surgido del grupo de soluciones informáticas del Children s Hospital de Boston, un hospital docente afiliado a Harvard. Ha llevado a cabo QA para GrantCentral, una plataforma de networking científica para investigadores afiliados a Harvard, así como la implementación de registros médicos controlados personalmente Indivo para el Consorcio de Dossia. Nicole ha participado activamente en el diseño y la implementación de Clickframes, un diseño y entorno de desarrollo de código abierto para aplicaciones web. Nicole fue ingeniera de QA experta para la Houghton Mifflin Corporation de Boston, Massachusetts, donde se hizo cargo de la calidad de Eduspace, una suite de potentes herramientas para la gestión de cursos y sistemas de gestión de contenido que permite a los profesores impartir todo el curso universitario, o parte de él, en línea. Anteriormente, Nicole había sido ingeniera de QA en Interlynx Technology donde lanzó InterAction, una herramienta de gestión de beneficios, y en roact Technologies, donde ocupó el cargo de Analista de negocios y Gerente de QA. Graham Thomas Consultor independiente, UK Graham escribió su primer programa informático en la universidad, en Empezó a trabajar en el sector de las TI a principios de la década de los 80 como programador y descubrió el testing de software a principios de la década de los 90. Cuenta con titulaciones oficiales en programación, análisis y diseño, gestión de proyectos y testing de software. Ha trabajado para una importante consultoría, varias empresas consultoras más pequeñas, para una empresa de sistemas y también para varios usuarios finales. Tiene una amplia experiencia en el sector de las TI y en el desarrollo y testing de software para la administración pública, los sectores minorista, financiero, bancario, asegurador y el tesoro público. Actualmente, Graham alterna su trabajo entre la gestión de pruebas en programas y la implementación de cambios vinculados al testing. Anteriormente había trabajado como gerente de pruebas. Es miembro del BCS SGST Standards Working arty, del que es secretario desde Ha participado como ponente en conferencias, seminarios y grupos de testing desde En esta presentación veremos como una herramienta (IRQA) nos ayudará a definir nuestros requisitos, pruebas de aceptación y validación de los mismos, trazas entre ellos, realizar análisis de impacto del cambio, gestionar peticiones de cambio y analizar su impacto en requisitos y pruebas, análisis de trazabilidad indirectos y como podremos reutilizar nuestro trabajo en requisitos y pruebas a diversos proyectos ahorrando el tener que reescribir o el copiar y pegar. onente: José Manuel Muñoz Fecha: 29/10/2009 El control de calidad del Single Source of Truth puede ir a la par de un entorno ágil El control de calidad desempeña un papel protocolario en el paradigma en cascada del SDLC, en que los requisitos ofrecen un fundamento autorizado para definir las pruebas de QA. Sin embargo, el paradigma de desarrollo ágil se ha convertido en predominante. En él, el diseño está en evolución continua y la función y los requisitos disponibles para el QA no están tan bien definidos. Entre en Clickframes, un entorno de código abierto y libre. El Single Source of Truth de Clickframes es un archivo XML que define una aplicación web. Contiene datos utilizables que definen todos los elementos de cada página de la aplicación. Ofrece la base para código Java a nivel de empresa funcional y código de pruebas Selenium, así como para artefactos de diseño y requisitos de software. A medida que el diseño de la aplicación se va refinando y mejorando, el Truth se actualiza. Inmediatamente, todos los artefactos reflejan el cambio. La organización del control de calidad aprovecha este modelo de diversas maneras. Los testers se pueden preparar rápidamente para el testing iterativo durante el ciclo de desarrollo ágil y están continuamente sincronizados con diseño y desarrollo, incluso cuando se escriben y ejecutan pruebas personalizadas más complicadas. El desarrollo ágil aprovecha el QA que se mantiene a la par con sus ciclos cortos mientras mantiene la precisión. El uso del Truth para facilitar las actualizaciones continuas lo permite. onente: Nicole Zanetti Fecha: 29/10/2009 Gestión de pruebas para programas muy grandes: kit de supervivencia Basándose en la experiencia práctica de diversos programas de testing grandes, esta presentación muestra las técnicas efectivas para una buena Gestión de pruebas en programas de desarollo, en forma de kit de supervivencia. or qué es necesaria? Si bien la función de Gerente de pruebas en programas ya está consolidada firmemente en el ámbito del testing, no existe una visión clara de lo que implica esta función, cómo se realiza o qué ventajas tiene en organizaciones de testing grandes o en programas grandes de decenas o centenas de millones de dólares. Debe ser el Gerente de pruebas en programas un superadministrador que lo controle todo, o tiene este puesto más bien una función de agregar e informar? Esta presentación se fijará en las expectativas del puesto y cómo estas pueden ser muy diferentes. También trata los factores críticos para una buena gestión de pruebas en programas, incluida la supervisión de los productos objetos del testing y de los entregables; la organización matricial de los gerentes de pruebas; la gestión de las partes implicadas, de los hitos, de los recursos y de las dependencias; y de las habilidades, menores aunque fundamentales, para influir y negociar con directores de alto rango. La conferencia ofrecerá ejemplos reales, relacionados con la experiencia obtenida en diversos programas de testing grandes basados en un modelo práctico (o kit de supervivencia), comprensibles para todo el mundo, que ilustran las principales áreas de gestión de pruebas clave en lo que respecta a la organización, las personas, el proceso, las herramientas y las mediciones que una organización puede adaptar a sus necesidades. Los asistentes habrán aprendido 1) Técnicas efectivas para la Gestión de pruebas en programas, 2) Consejos seleccionados fruto de la experiencia práctica y 3) Un modelo práctico (kit de supervivencia) para la Gestión de pruebas en programas. onente: Graham Thomas 19 con traducción

20 Expositores Colaboradores 20 AI2 Cibersur ALI ETICOM ATI INTECO