Fecha: 17/11/2010

¿Cuándo estará listo el sistema para su lanzamiento? (y cómo evaluarlo)

El objetivo del testing es poder responder a la pregunta "¿Cuándo estará listo el sistema para su lanzamiento?"

Las sencillas respuestas a esta pregunta son las siguientes:

1. Cuando se disponga de la cobertura de pruebas adecuada.
2. Cuando se hayan encontrado todos los defectos que se esperaba encontrar (y se hayan solucionado los suficientes)
3. Cuando el sistema sea estable.

Esta charla analiza los medios disponibles para responder estos puntos de manera en que convenzan a la dirección y se ilustra con estudios de caso.

Ponente(s): Peter Farrell-Vinay

Fecha: 17/11/2010

Evaluación e implementación de las herramientas de pruebas

Pese a que existen incontables lecciones por aprender a la hora de comprar herramientas para pruebas, seguimos cometiendo los mismos errores que cometíamos hace diez años, y acabamos teniendo una estantería llena de software caro que no utilizamos como parte de nuestro conjunto de herramientas para pruebas. Muchas empresas no llegan a evaluar correctamente las herramientas para pruebas disponibles actualmente en el mercado y, en consecuencia, compran herramientas que sólo realizan el trabajo parcialmente o que requieren demasiado tiempo y recursos para conseguir lo que se espera de ellas. En esta charla, Graham Moran explica un proceso especialmente diseñado para evaluar e implementar herramientas para pruebas y comenta algunas de las dificultades que se pueden encontrar las empresas cuando intentan adquirir estas herramientas.

Ponente(s): Graham Moran

Fecha: 17/11/2010

Mejorar los resultados económicos de las empresas a través de actividades de calidad del software que contribuyan al ahorro

En la situación actual en la que nos encontramos, cuando existe la imperiosa necesidad de recortar gastos, lo inteligente es aplicar medidas que contribuyan al ahorro y no introducir aquellas que paralizan actividades a las que no se puede renunciar para conseguir la estabilidad y el progreso que los negocios necesitan. En esta coyuntura, los gestores públicos y privados bien podrían detenerse a considerar recetas aún desapercibidas, mal entendidas o incorrectamente desarrolladas dentro de las propias áreas de tecnología; pero no a través del tradicional y manido discurso de la optimización de los costes tan utilizado en el sector de las TIC.

Durante 2009, y según datos de consultoras especializadas, sólo las administraciones públicas españolas gastaron en desarrollo y mantenimiento de aplicaciones software unos 1.100 millones de euros. Si desde ese año hubieran realizado actividades de pruebas y calidad de software, en 2013 -fecha en la que existe el compromiso con la Unión Europea de volver al Pacto de Estabilidad reconduciendo el déficit hasta el 3%- habrían ahorrado 750 millones de euros durante todo el periodo, a razón de 125 millones al año. Pero este es sólo un ejemplo de la aportación que la actividad aseguramiento y control de la calidad del software, bien introducida y bien gestionada, podría aportar a la mejora de los resultados de las compañías.

Así pues, colaborar en la mejora de los resultados y en la reducción del déficit de las compañías es factible a través de la introducción de prácticas de aseguramiento y control de la calidad del software pero ¿qué hacer y cómo hacer para conseguirlo? Durante la ponencia se darán algunas claves para tratar de alcanzar este objetivo.

Ponente(s): Francisco Sáez

Fecha: 17/11/2010

Reconciliando Mundos con MS Test Manager

De todos es conocida la guerra constante entre el mundo del desarrollo y el mundo de las pruebas de software; al fin y al cabo, los unos cometen errores, y los otros encuentran defectos. Tradicionalmente, otros proveedores de software han planteado un acercamiento a esta situación que no hace sino empeorar la guerra entre los mundos del desarrollo y pruebas, forzando a probadores y desarrolladores a trabajar con herramientas y entornos separados. Para un desarrollador tener que abrir otra herramienta para ver que defectos han sido encontrados por los probadores es un engorro; para un tester trabajar sobre un entorno que está en constante cambio de versión y datos es un problema.

Durante esta charla, Jose Aracil hablará de sus experiencias en este tipo de organizaciones donde el mundo de las pruebas está en constante guerra con el mundo del desarrollo. Jose explicará como Microsoft Test Manager es capaz de reconciliar esta situación, y hacer que probadores y desarrolladores trabajen juntos para obtener un producto de excelente calidad. A lo largo de la ponencia se expondrá de forma práctica como Microsoft Test Manager soluciona los problemas comentados y provee de la información necesaria para conocer el estado de la calidad del software desarrollado.

Ponente(s): José Aracil

Fecha: 17/11/2010

Metodología para el testing de la accesibilidad para personas con discapacidad visual en entornos web

Actualmente, el mundo vive la era de la inclusión digital y la accesibilidad de las páginas web se ha convertido en una preocupación global, puesto que este entorno desempeña un papel principal en la vida diaria de las personas con necesidades especiales. Este componente facilita la vida de estas personas; con él pueden relacionarse de manera diferente y llevar a cabo actividades que antes les resultaban imposibles.

El gobierno brasileño decretó que todos los sitios de la administración pública debían ser accesibles, hecho que ha servido de ejemplo a otros países. Por estos motivos, este trabajo tiene como objetivo elaborar una metodología para comprobar la accesibilidad a la hora de inspeccionar todas las fases del proyecto, desde su concepción, cuando se traza el plan de pruebas, hasta la entrega, después de examinar los resultados de las pruebas, anticipar los errores, generar menos revisión del trabajo, reducir los costes del proyecto y conseguir así que se otorgue la debida importancia a la accesibilidad.

Ponente(s): Virgínia Chalegre

Fecha: 17/11/2010

Transformación de las Aplicaciones y Aseguramiento Continuo de la Calidad para alcanzar los objetivos de negocio

Día con día las empresas confían en software y otras tecnologías para mantener en funcionamiento las aplicaciones corporativas críticas para el negocio. Su éxito depende de que éstas trabajen de manera efectiva y que cumplan con los requisitos para las que fueron diseñadas.
Desafortunadamente no siempre es así, de manera que los Directores de Tecnologías se enfrentan con diferentes retos para mantener el desarrollo de software alineado con el negocio:

- Reducir los costes asociados
- Incrementar la calidad del diseño y desarrollo
- Reducir riesgos de migración
- Incrementar la agilidad/flexibilidad del negocio

Esta ponencia habla sobre estos retos y da un punto de vista de cómo reducirlos.

Ponente(s): Belén Bernardos

Fecha: 17/11/2010

Lo que significa la Calidad del Software para el negocio

Como antiguo CIO de Allianz y Paribas, Paul Benz ha tenido una experiencia directa con los retos a los que se enfrentan los Ejecutivos de TI a la hora de dar servicio a una comunidad de usuarios de negocio cada vez más exigente.

Si hablamos solamente de la gestión de la complejidad y el rendimiento de un sistema de información, en los últimos años, se ha avanzado mucho en las áreas de infraestructura y gestión de proyectos.

Curiosamente, hasta ahora, la preocupación por la calidad interna de las aplicaciones de negocio ha sido menor, mientras que actualmente se está convirtiendo en el foco de la gestión de los nuevos modelos de compras y de la preocupación por los riesgos operacionales.

El Sr. Bentz siempre ha tratado de encontrar fórmulas para gestionar los riesgos, medir los resultados y establecer un gobierno para la entrega de aplicaciones, que permitiera la evaluación comparativa.

Como asesor de CAST, el Sr. Bentz explicará por qué y cómo CAST proporciona a grandes empresas de todo el mundo la capacidad inmediata para minimizar los riesgos empresariales, reducir significativamente los costes de TI y obtener una información objetiva del rendimiento de los equipos de desarrollo de TI, tanto internos como externos.

Ponente(s): Paul Bentz

Fecha: 17/11/2010

Gestión de pruebas orientada al negocio en Panda Security

Panda Security ha implementado una serie de mejoras y prácticas propuestas en un proyecto de consultoría de Gestión del ciclo de vida del producto realizado en 2008 que ha impulsado significativamente el nivel de calidad de sus productos y el control sobre los procesos de desarrollo y QA.

A finales de 2009, se observó la necesidad de mejorar el equilibrio entre la inversión en control de calidad y los requisitos concretos del negocio. Panda invitó a Sogeti España a estudiar y optimizar su estrategia de pruebas y los procesos de estimación. Desde diciembre de 2009 a febrero de 2010, un consultor de Sogeti analizó el nivel de madurez de los procesos de gestión de pruebas de las divisiones de QA y las relaciones de las partes implicadas. Gracias al modelo de mejora de gestión de pruebas TPI®Next, Sogeti diseñó y aplicó un proceso acorde a la madurez y los objetivos de Panda, según la filosofía de gestión orientada al negocio Tmap®Next.

Para mejorar la visibilidad y las relaciones con las partes implicadas del negocio y la tecnología, la misión de las divisiones de QA se ha establecido en una política de QA y detallado en una estrategia de QA organizativa.

El proceso y las plantillas de estrategia de pruebas resultante se han aplicado hasta ahora en dos proyectos, y actualmente se está desplegando en los grupos de certificación restantes, de manera que se hayan implementado completamente a finales de junio de 2010.

Ponente(s): Miriam Serna, Ewout van Driel

Fecha: 17/11/2010

INVITADO: Mercado de servicios de testing a escala mundial para el período 2010-2014: oportunidades clave de crecimiento y tendencias del sector

En el pasado, el testing ha solido pasar desapercibido respecto al peso que tiene en la empresa así como por su contribución a los costes de TI anuales. A menudo, en muchas organizaciones esta situación se ha reflejado en los desarrolladores que realizan testing durante el curso de un proyecto. Así, el coste real de testing quedaba frecuentemente diluido en el presupuesto general de desarrollo y se sacrificaba el rigor del testing a fin de cumplir las fechas límite de lanzamiento.

Recientemente, diversos factores han influido a la hora de convertir los servicios de testing en una de las principales prioridades de los encargados de tomar decisiones de TI: la renovada presión que se ejerce sobre las TI para que colaboren en los programas de reducción de costes a todos los niveles de la empresa como consecuencia de la desaceleración económica y un mayor reconocimiento de los efectos negativos que un testing ineficaz, insuficiente o mal dirigido puede ocasionar en las empresas. Cada vez con más asiduidad, los medios han destacado fallos del sistema, más allá de interrupciones en las actividades, con el consiguiente perjuicio a la imagen.

El gasto mundial en testing (incluidas las habilidades de testing internas y externas, las herramientas y el hardware y los sistemas relacionados) seguirá aumentando más rápidamente que el mercado de TI y podría alcanzar el listón de los 100.000 millones de euros en 2014.

Asimismo, el testing se está convirtiendo en uno de los ámbitos más sólidos de selección de personal en el sector de las TI y la consultoría PAC estima que actualmente existen más de 100.000 testers profesionales en todo el mundo.

El reciente informe "Worldwide Testing Services" escrito por dos consultores de PAC, Nick Mayes (PAC Reino Unido) y Arnold Aumasson (PAC Francia), arroja datos claros sobre el mercado de servicios de testing de software global, uno de los campos más dinámicos del sector de servicios de las TI.

Ponente(s): Arnold Aumasson

Fecha: 17/11/2010

KEYNOTE: Lo que los gerentes creen conocer sobre la automatización de pruebas pero en realidad ignoran

Estudios recientes han hecho hincapié en el papel crítico que desempeñan los gerentes en el éxito o fracaso de la automatización de las pruebas. Sin un apoyo de gestión adecuado, iniciativas bien intencionadas se ven condenadas a una vida corta y a provocar un desperdicio de tiempo y dinero. Aún así, un amplio apoyo de gestión sin un conocimiento profundo de los problemas puede impedir que se consigan resultados con beneficios duraderos y progresivos para la organización.

En esta charla, Dorothy Graham define los errores conceptuales que afectan comúnmente a la gestión en el campo de la automatización y cómo asegurar que las expectativas son realistas. Sepa por qué los objetivos y la medición son críticos para la automatización de las pruebas y cómo los objetivos para la automatización difieren de los objetivos de las pruebas, cómo determinar el alcance, estimar y aportar recursos a los esfuerzos de automatización de pruebas y cómo medir el retorno de la inversión, entre otros temas. Identifique qué puede actuar como indicación inicial de problemas y sepa cómo recuperar el tiempo perdido para conseguir una automatización eficaz.

• entienda qué papel desempeña la gestión en una automatización eficaz y sepa cómo dirigir para alcanzar el éxito
• evite errores comunes que los gerentes cometen en la automatización del testing
• sepa qué supervisar y cómo recuperar el tiempo perdido

Ponente(s): Dorothy Graham

Fecha: 17/11/2010

El síndrome de Casandra: el dilema del tester y cómo reaccionar

Aportar contribuciones positivas para que el software sea un éxito puede representar todo un reto para los ingenieros de pruebas y QA, en lugar de actuar de manera "negativa", es decir, buscar problemas, predecir problemas, evitar problemas e informar de los problemas. Esta perspectiva "negativa" se enfatiza en títulos de libros de software como "How to Break Software" (Cómo romper software).

Mientras unos centran su proyecto en conseguir que el software funcione, los testers se centran en encontrar maneras en las que no funcione. Estos puntos de vista divergentes tienen el potencial de interferir en la comunicación, la cooperación y la eficacia del equipo, así como repercutir en la satisfacción laboral. El QA y las pruebas pueden percibirse como miembros de equipos contrarios con una "actitud negativa".

Este problema no es exclusivo de los proyectos de software. De hecho, es un factor humano tan recurrente que adquirió un papel protagonista en una de las más famosas obras literarias de todos los tiempos, la Ilíada de Homero, la compilación de mitos y leyendas griegos del siglo VII a. C. La Ilíada incluye la historia de Casandra y el sitio de la antigua ciudad de Troya. Casandra poseía el don de la profecía pero la maldición de no tener a nadie que escuchase sus profecías. En alguna ocasión, muchos testers se han sentido como Casandra. No se ha hecho caso de la predicción de problemas inminentes en un proyecto. Es posible que los ingenieros de QA hayan previsto que una fecha de entrega no se va a cumplir si no se siguen los procesos, pero nadie les ha prestado atención. La presentación tratará sobre qué podemos aprender de la historia de Casandra, y qué se puede hacer para contrarrestar el "síndrome de Casandra".

Ponente(s): Rick Hower

Fecha: 17/11/2010

Outsourcing de Servicios de Pruebas con TTCN3

La externalización de servicios de pruebas utilizando la metodología TTCN3 es una solución cada vez más adoptada por las compañías que cuentan con reducidos presupuestos. En la actualidad se tiende a externalizar parte de las actividades de testing, concretamente, los desarrollos y pruebas realizadas con TTCN3 son susceptibles de llevarse a cabo de forma remota. Esta situación permite a las organizaciones obtener una ventaja competitiva y financiera para aquellas que ya utilizan TTCN3, incluso para las empresas que se están planteando introducir esta metodología en sus procesos de pruebas. Por ejemplo, las pequeñas y medianas empresas pueden beneficiarse de las ventajas y aplicaciones que tiene TTCN3 en el proceso de pruebas en cuanto a la externalización, que de otra forma resultaría mucho más costoso y en ocasiones improbable de llevar a cabo.

El éxito en este tipo de proyectos se basa en el establecimiento de una metodología probada y enfoque consolidado de las actividades de pruebas con TTCN3. En la medida en que va aumentando el volumen de servicio de pruebas con TTCN3 en modo deslocalizado también crecen las relaciones entre los equipos de cliente y proveedor, lo cual representa un reto dentro del proyecto que ha de ser óptimamente gestionado. Esta presentación nos dará luz sobre los puntos clave a tener en cuenta a la hora de externalizar los proyectos de pruebas con TTCN3.

La prestación de servicios de pruebas con TTCN3 de forma deslocalizada, trae consigo una claro beneficio financiero y de ejecución a tener en cuenta por las pequeñas, medianas y grandes empresas.

MTP tiene una probada experiencia en ofrecer y llevar a cabo proyectos deslocalizados de pruebas con TTCN3. En esta presentación vamos a conocer los beneficios de esta metodología y la forma de prestación del servicio.

La metodología incluye: continuidad y control de entregables, flexibilidad del proyecto que permite trasladar las actividades de prueba de modo onsite a offshore, revisiones continuas para la detección rápida de errores, control del presupuesto en los análisis iniciales de proyecto, relación con el cliente, proximidad cultural, innovación y precio basado en el coste por scripts y no en el tiempo dedicado a la creación, ejecución y desarrollo de scripts.

Ponente(s): Raquel Jiménez Garrido

Fecha: 17/11/2010

Pasos para construir un Centro de Excelencia de Aseguramiento de la Calidad

Dado que el testing una actividad clave, se discutirá una hoja de ruta para la construcción de un centro de competencia, partiendo a pequeña escala y trabajando en la construcción del mismo a lo largo del tiempo. El objetivo final es establecer un Centro de Excelencia (CoE), con el compromiso de alcanzar la eficiencia, coherencia, sentido práctico, además de una carrera para su equipo de pruebas, que reducirá significativamente sus costes, acelerara el tiempo de comercialización y reducirá su exposición al riesgo.

Antes de meternos con los pasos necesarios para construirlo, vamos a revisar las razones para embarcarse en este viaje: ¿Por qué debiera usted considerar un CoE? ¿Qué puede esperar del CoE? ¿Quién va a participar?

Luego pasaremos al siguiente nivel: ¿Cuándo y dónde debo implementarlo? ¿Cómo debo hacerlo? Poner en marcha un CoE supondrá involucrar a numerosas personas, procesos y tecnología, así como la toma de una serie de decisiones, como: ¿se quiere favorecer un sistema centralizado o un modelo descentralizado? A través de una serie de medidas prácticas vamos a revisar cuáles son las implicaciones de estos factores, sin olvidar que dos organizaciones nunca lo implementarán de la misma manera.

Vamos a poner la guinda con una demostración en vivo en la que se verá como una solución estándar para un sector concreto puede ayudar a acelerar la adopción y materialización de los beneficios del CoE.

Ponente(s): Cesar Franco

Fecha: 17/11/2010

Cómo seleccionar las técnicas de diseño de testing más efectivas

Pese a que se encuentra mucha información sobre técnicas de diseño de testing, la documentación disponible no explica demasiado cómo seleccionar las que se tienen que utilizar.  Para muchos testers, seleccionar las técnicas adecuadas resulta difícil. Muy frecuentemente, una técnica de diseño se utiliza por el simple hecho de que ofrece la posibilidad de uso. Cuando se selecciona una técnica, el motivo principal debería ser "los errores que no queremos tener en nuestro sistema de producción". Los testers deberían comprender mejor la relación entre tipos de errores y las técnicas que ayudan a localizarlos. Este entendimiento derivará en un mejor uso de técnicas y permitirá plantear las preguntas apropiadas a las partes implicadas. Con el uso de las técnicas correctas, el tester lleva a cabo las pruebas adecuadas y es responsable de sus acciones y de la calidad de sus recomendaciones. Puesto que las técnicas definen las pruebas que se llevan a cabo, determinan, a su vez, la información que se puede facilitar a las partes implicadas. 

La selección de las técnicas que se van a utilizar es un proceso meticuloso. Seleccionar la técnica equivocada puede implicar una gran pérdida de tiempo sin encontrar muchos errores o información útil. No optar por la técnica apropiada puede conllevar que no se encuentren defectos importantes. Explicaré el modelo de decisiones según comento en mi libro, e invertiré el problema. No utilizamos técnicas por el mero hecho de que podamos hacerlo, sino porque nos ayudan a facilitar la información adecuada. A diferencia de muchos métodos, partimos de los errores y seleccionamos las técnicas que ayudan a localizarlos.

Ponente(s): Derk-Jan de Grood

Fecha: 17/11/2010

Pentest como verificación del nivel de seguridad en aplicaciones web

Afortunadamente, cada vez más organizaciones incorporan una estrategia de seguridad al SDLC, entendiendo así la estrategia de adoptar un conjunto de mejores prácticas que ayuden a la organización a asegurar un nivel de seguridad efectivo y eficiente, necesario para los desarrollos que se realizan. Se pueden utilizar muchos entornos como guía para la implementación de estas estrategias, como OpenSAMM (Open Software Assurance Maturity Model), BSIMM (Building Security in Maturity Model), Security Software SDL Touchpoints y Microsoft, entre otros.

Cada aplicación requiere un nivel de seguridad, se debe tener claro qué evidencia se lleva a cabo, cómo se realiza y qué objetivos se persiguen.

Una actividad imprescindible en el proceso de desarrollo del software seguro, y en cualquier disciplina (como entornos de seguridad anteriores) debe incluir entre sus objetivos el testing de seguridad.

Esta presentación abordará estos aspectos y técnicas utilizados actualmente para llevar a cabo una revisión exhaustiva de estas aplicaciones.

Ponente(s): Vicente Aguilera Diaz

Fecha: 17/11/2010

Testing... tantos problemas. Pero tenemos soluciones, ¿verdad?

Sir Humphrey Davy dijo "Mis descubrimientos más importantes los han inspirado mis fallos".

Esto sigue siendo tan cierto hoy como cuando lo dijo Sir Humphrey. He trabajado en el ámbito de la mejora del proceso de pruebas durante muchos años y veo como los mismos problemas se repiten una y otra vez. Por ejemplo, veo a los testers culpando a los demás por los problemas que tienen con los requisitos pero no haciendo nada por solucionar estos problemas. Veo como muchos equipos de pruebas inician un proyecto y parece que empiecen de cero cada vez: repiten todos los errores y asumen los mismos riesgos de siempre, es como si no aprendiesen nunca o no quisiesen aprender.

Como profesión, debemos fijarnos en nuestros errores habituales y comprender por qué han ocurrido y qué podemos hacer para que no vuelvan a ocurrir, y, quién sabe, a lo mejor encontramos el remedio milagroso para el testing.

Esta presentación ofrecerá una visión general de los problemas comunes a los que se enfrentan los testers actualmente (patrones de problemas) desde varias perspectivas:

• Una mirada desde fuera del proyecto de pruebas
• Organización de pruebas
• Gestión de pruebas
• Entorno de pruebas
• Diseño y ejecución de pruebas
• Automatización de pruebas

junto a varias recomendaciones para saber cómo evitarlos en el futuro.

Ponente(s): Geoff Thompson

Fecha: 17/11/2010

Expectativas y Percepciones de la Calidad de Software: ¿una misión imposible?

El planteamiento de la presentación es la evaluación del servicio de calidad o aseguramiento de la calidad de software desde los criterios: "expectativas" y "percepciones".

En la actualidad, consideramos "madura" la implantación de sistemas de calidad de software apoyados en estándares y buenas prácticas; sin embargo, estos sistemas están basados en su mayoría en metodologías abstractas y su aplicación directa, sin analizar las necesidades y expectativas de cada dirección, organización, o cliente, suele ser poco satisfactoria.
Por ello, planteamos una reflexión basada en dos perspectivas: una, relativa a las expectativas de los clientes y, otra, relativa a las percepciones. La diferencia o discrepancia que existe entre ambas nos dará la medida de la calidad del servicio.
La clave para facilitar un servicio de calidad de software en las organizaciones de TI radica en equilibrar las expectativas y las percepciones y conseguir así una mejora del servicio. Planteemos por tanto algunas cuestiones: ¿Es necesario hablar de tipos de calidad de software?, ¿Debemos plantear una calidad de software dirigida a objetivos?, ¿Quién es el beneficiario de nuestras acciones? En efecto, en muchas ocasiones las estrategias para satisfacer a los distintos clientes de las tecnologías de la información son antagónicas y, por tanto, incapaces de satisfacer las expectativas de estos.

Ponente(s): Salvador Folgado

Fecha: 17/11/2010

Pruebas de carga en un día “Cloudy”

Nos centraremos en el arte de realizar pruebas de carga y de rendimiento. ¿Qué puede esperar para mañana? ¿Cómo debe usted desarrollar sus prácticas de pruebas de carga para adaptarse al ciclo de vida del desarrollo de aplicaciones?

Empezaremos por el principio: "¿Por qué una prueba de carga es parte central de cualquier proceso de pruebas para una implementación exitosa?". Usted comprenderá la complejidad de las pruebas de rendimiento y sabrá por qué no se considera como una tarea fácil u opcional.

Además, esto le dará una idea de la importancia de utilizar la metodología adecuada para hacer frente a los desafíos más recientes del sector. Tarde o temprano, tendrá que lidiar con la complejidad que representan nuevas tecnologías tales como aplicaciones dinámicas de Internet o el uso del "Cloud". Entenderá cómo sus recomendaciones pueden tener un impacto positivo en las elecciones de su organización.

Por último, se le darán las claves para ejecutar las pruebas de carga y rendimiento ganando en productividad y flexibilidad. Podrá dar más valor a las partes implicadas y ganará respeto a cambio.

Después de asistir a esta presentación, estará preparado para lo que viene en el futuro. Sabrá cuáles son las preguntas clave que debe plantearse. De esta manera será capaz de dar las recomendaciones justas para ayudar a mejorar la calidad de las aplicaciones probadas y la eficacia de su equipo.

Puntos clave:
1 ¿Por qué las pruebas de carga y de rendimiento no son sólo opcionales o por ser hechas si usted tiene tiempo suficiente?
2 Maneje la complejidad, las últimas aplicaciones web y el "Cloud".
3 Desarrolle sus prácticas y ofrezca más valor y eficacia a sus grupos de interés.

Ponente(s): Thomas Ripoche

Fecha: 17/11/2010

Mejores prácticas en la entrega de soluciones de calidad en un entorno distribuido y ágil

Actualmente las organizaciones que se dedican a la entrega de software están sometidas a fuertes presiones para producir software de una manera mucho más rápida y para contener los costes en un modelo de desarrollo de software cada vez más globalizado. ¿Cómo podemos afrontar esas presiones sin menoscabo de la calidad de nuestras entregas de software?

En esta presentación se explorarán los cambios acontecidos en los últimos años en los modelos de entrega de software y las formas en las que  podemos gestionar la entrega de software en los entornos actuales. De forma especial se verán varios casos reales en los que grandes empresas comerciales han conseguido relevantes mejoras en la calidad del software al adoptar prácticas más ágiles. La exposición finalizará con un conjunto de mejores prácticas para adoptar "agile at scale" que se pueden aplicar en tu propia organización para obtener mejoras de calidad medibles en tu modelo de entrega de software.

Ponente(s): Alan Brown

Fecha: 18/11/2010

TPI Next: el paso siguiente en la mejora del proceso de pruebas

La metodología Test Process Improvement (TPI®) ha sido decisiva para ayudar a muchas organizaciones en la mejora de sus procesos de pruebas generales, una iniciativa esencial para asegurar la calidad de los sistemas de información y procesos empresariales críticos. Al aportar elementos de entendimiento a la madurez del proceso de pruebas, TPI ha brindado pasos lógicos y prácticos para mejorar la eficiencia y la eficacia de las pruebas, además de instilar la convicción de haber conseguido un ciclo de mejora permanente.

Ponente(s): Augusto Sagrario

Fecha: 18/11/2010

¡Socorro! ¡Tenemos un problema de QA!

Esta es la historia real en que muchos desarrolladores daban trabajo a muy pocos testers provocando un retraso en el testing de medio año, con muchos clientes molestos que esperaban demasiado para conseguir la solución a sus problemas. Un tester experto acababa de irse de la empresa. Solo quedaban un tester experto y otro principiante. Iban afrontando la enorme acumulación de trabajo sin saber por dónde empezar.

Demostraremos cómo el empoderamiento de los testers, la planificación meticulosa y la implicación de los desarrolladores permitieron a los testers recuperar el ritmo en unas nueve semanas, a la vez que iban satisfaciendo las necesidades de cada uno de los clientes. El tester experto aprendió cómo planificar el trabajo de los testers de manera eficaz y eficiente en sincronización con los desarrolladores, de manera que desde entonces no ha vuelto a haber ninguna otra acumulación de trabajo. Se recuperó la confianza de los clientes que, durante el proceso, querían cambiar de proveedor; este hecho derivó en un enorme crecimiento de los ingresos desde ese momento.

En primer lugar, mostraremos cómo utilizamos las técnicas de planificación evolutiva en este caso concreto. A continuación, comentaremos con términos más generales los elementos de esta técnica de planificación. La respuesta a la pregunta "¿Quién es el cliente de testing?" normalmente causa sorpresa en la mayor parte del público. Sin embargo, suele ser una sorpresa relacionada con el reconocimiento.

Ponente(s): Niels Malotaux

Fecha: 18/11/2010

Estimación de los recursos implicados en un proyecto de pruebas

En esta ponencia presentaremos un método de estimación de los recursos necesarios para la realización de las actividades de Verificación y Validación de un Sistema de Software Crítico y Complejo.

De esta forma, definiremos:

• el alcance de las pruebas a realizar dentro de un proyecto de desarrollo software
• la estructura básica de los miembros de un equipo de pruebas y actividades a realizar,
• los ratios y métricas que sirven para la estimación de los recursos a utilizar, como son:
  • Número de requisitos del sistema
  • Planificación inicial de las actividades de pruebas
  • Número de pruebas necesarias para los requisitos (utilizando valores históricos en proyectos relacionados)
  • Número de pruebas diseñadas por Ingeniero de Prueba
  • Número de pruebas ejecutadas por Ingeniero de Prueba
  • Número de pruebas ejecutadas con incidencias
  • Número de pruebas de regresión
  • Número de Incidencias esperadas
  • Porcentaje de cambios a la documentación de requisitos del sistema
  • Impacto de los cambios en las pruebas

 

A lo largo de toda la presentación se mostrarán valores estimados y valores reales, obtenidos en un caso práctico de un Sistema de Control de Tráfico Aéreo.

Ponente(s): Juan Luis Valera Juanas

Fecha: 18/11/2010

Aseguramiento de la calidad de servicio: una perspectiva global

Volviendo a lo básico, una pregunta que se plantea recurrentemente es "¿Por qué testear?". La siguiente que quizás se plantearía es "¿Qué testear?".

En la mayor parte de organizaciones, las labores de testing se justifican por los grandes beneficios que aportan a la correcta funcionalidad, disponibilidad y rendimiento de las aplicaciones y servicios clave de negocio. Estos servicios de negocio se ven sujetos a múltiples situaciones en las que su funcionalidad se ve comprometida: nuevas versiones de aplicaciones, nuevas aplicaciones, consolidaciones, optimizaciones, migración/upgrade de infraestructura, cambios de arquitectura. ¿Cuáles y cuántos de estos cambios se testean?. ¿Cómo?. ¿Por qué?. ¿Por qué no?.

Bajo esta perspectiva, revisaremos nuestras experiencias y casos reales de clientes ejecutando todo tipo de pruebas, tanto en fases de prueba funcional como en labores de diagnóstico, pruebas de integración de sistemas, migración y consolidación de infraestructura. Analizaremos con una perspectiva totalmente práctica aspectos fundamentales para asegurar un proceso exitoso de pruebas, como la gestión de la configuración de los entornos de pruebas y los juegos de datos utilizados en los mismos. Adicionalmente, revisaremos las mejores prácticas y casos de éxito de nuestros clientes en la implantación de centros de excelencia de testing, despliegue de software y aplicaciones empaquetadas, optimización de infraestructura, proyectos de alta disponibilidad de datacenters, etc.

Finalmente, revisaremos de forma práctica las capacidades integradas de las soluciones de Oracle Application Quality Management de proveer beneficios tangibles en la gestión de ciclo de vida de los servicios de negocio, proporcionando soluciones alrededor de múltiples fases del citado ciclo de vida.

Ponente(s): Iván Menéndez

Fecha: 18/11/2010

KEYNOTE: Cómo conseguir que crezca el sector: cultivar el testing

Aunque el testing de software es una disciplina relativamente joven, la inmadurez no es el único motivo por el que seguimos desarrollando nuestros métodos, calificaciones profesionales, asociaciones comerciales y posicionamiento en el sector del software y en la sociedad. Todas las profesiones de éxito deben evolucionar y crecer continuamente.
La pertenencia a una profesión implica una expectativa de comportamiento, calificación y experiencia, regulada por un organismo profesional. Necesitamos comprender si es deseable o posible ser una profesión, y saber cómo regularnos para favorecer a nuestros clientes, al sector y a los usuarios.

El testing de software no es la única actividad o sector que intenta convertirse en lo que representa ser una profesión; el sector de la horticultura también atraviesa por un debate parecido: si es deseable, factible o necesario adquirir el estatus de profesión. La horticultura se ha practicado durante unos 8.000 años más que el testing de software. Durante estos milenios, las prácticas de la horticultura han seguido evolucionando, gracias a los descubrimientos casuales, un mayor entendimiento científico y una tecnología mejorada. Al igual que la horticultura, el testing de software es un sector multidisciplinar impulsado por la ciencia y la tecnología con implicaciones políticas, sociológicas y económicas.

Los horticultores y los testers de software deben tener en cuenta lo siguiente:

• Cómo se ha utilizado la regulación en otras actividades y sectores a medida que se han ido convirtiendo en profesiones
• El papel que desempeñan los organismos profesionales a la hora de controlar y regular a los profesionales
• El papel que desempeñan los estándares, las calificaciones y los conjuntos de conocimientos a la hora de controlar y regular los niveles de entrada y práctica para las profesiones y actividades
• El papel de la supervisión y regulación a la hora de mantener los estándares de comportamiento y práctica.

 

Historial de la presentación: ponencia destacada de gran acogida en la EuroSTAR2007, con igual éxito en la Eriksson Conference 2008 y en la SIGiST de Londres 2010.

Ponente(s): Isabel Evans

Fecha: 18/11/2010

No basta con construir el sistema correctamente, debemos construir el sistema correcto: Requisitos y Pruebas en IRQA

Requisitos y pruebas son un elemento clave en calidad, ambos serán necesarios, así como las trazas entre ellos, para poder construir un sistema, saber que probar y aceptar dicho sistema. Las pruebas no solo deben indicarnos que el sistema funciona correctamente sino que hemos construido el sistema correcto. Durante esta presentación se nos mostrará como IRQA, herramienta líder en ingeniería de requisitos, nos brinda soporte para definición de pruebas, crear trazas entre las mismas y los requisitos y como IRQA puede ayudarnos a validar la especificación de requisitos y pruebas. Así mismo, se planteará un escenario donde podremos ver como es posible la generación automática de pruebas desde los casos de uso, la gestión de las ejecuciones de dichas pruebas y el seguimiento de las pruebas y los requisitos por medio de trazas, informes y dashboards (paneles de mandos).

Ponente(s): José Manuel Muñoz

Fecha: 18/11/2010

¿Cómo mejorar el software para facilitar su mantenimiento?

Resulta bien conocida la distribución de costes del software de aplicación, y cómo el mantenimiento (evolutivo, correctivo o preventivo) constituye "la parte del león" en el coste total que las aplicaciones tienen para las organizaciones usuarias.

Estándares como ISO 9126 definen la capacidad de ser mantenido ('mantenibilidad') como una característica clave en la calidad del software. Desgraciadamente, las métricas recomendadas por estos estándares suelen obtenerse 'a posteriori': Inciden sobre la eficacia del proceso de mantenimiento, pero carecen de capacidad de explicar qué características del software lo dificultan, y por consiguiente no facilitan tomar medidas técnicas concretas que reduzcan este coste de mantenimiento.

La ponencia, presenta diferentes modelos orientados a medir directamente (mediante métricas de producto) la mantenibilidad en el software y sus subcaracterísticas: estabilidad, facilidad de análisis, cambio y prueba. Se analizan las propiedades de estos modelos, y se propone uno que cumple unos objetivos clave (independencia de tecnología, medidas fáciles de computar, capacidad explicativa) que permiten su aplicación a los entregables de un proyecto de desarrollo software.

Se expone la aplicación de este modelo práctico a diferentes escenarios de desarrollo software (desarrollo interno, desarrollo externalizado, factorías de software...) y tecnológicos, y cómo éste permite identificar medidas de carácter preventivo que mejoran la mantenibilidad futura del sistema software, tanto en fase de desarrollo como de mantenimiento.

La ponencia finalizará mostrando cómo se ha implantado este modelo en checKing QA, el cuadro de mandos de calidad de Optimyth Software.

Ponente(s): Luis Rodriguez

Fecha: 18/11/2010

Cómo externalizar el testing de manera eficaz

Al externalizar todos o parte de las tareas de testing a un proveedor externo, es preciso contar con un enfoque especial para que el testing sea efectivo y esté controlado. Martin Pol explica los pasos que se deben seguir para externalizar de manera eficaz. Cómo definir los objetivos y el alcance, qué tareas se deben externalizar y qué tareas no, al menos no de momento. Explica cómo seleccionar el proveedor y cómo migrar, implementar y gestionar los problemas organizativos. Martin comenta contratos, acuerdos de nivel de servicio, temas de compensación así como la supervisión y el control del trabajo de testing externalizado, incluidas métricas específicas.

Buenas noticias para los testers: la externalización necesita más testing, no menos, y en consecuencia están apareciendo nuevos trabajos de testing. El testing de la externalización se está convirtiendo en un mecanismo de control muy importante para la externalización en general.

Ponente(s): Martin Pol

Fecha: 18/11/2010

Gestión de pruebas Lean: no malgastar y ganar eficiencia

Las reducciones de costes y la búsqueda de una mayor eficiencia son más evidentes en el mundo empresarial actual. De esta tendencia se deduce que nuestros procesos de testing se verán afectados en última instancia. Muchas teorías de gestión se refieren a "Lean" como una de las soluciones.

Uno de los pasos clave de utilizar "Lean" es la identificación de los pasos que aportan valor y los que no. Esta presentación analizará el uso de "Lean" en el testing y más concretamente en la gestión de pruebas. Como orientación, el presentador seguirá el "Proceso de Lean manufacturing": la filosofía de gestión de procesos genéricos derivada del Sistema de Producción Toyota. Se distingue por centrarse en la reducción de los siete tipos de "desperdicio" para mejorar el valor general al cliente. Todo aquello que no aporte valor al cliente se considera desperdicio.

Esta presentación se centrará en los diversos elementos según se ha descrito anteriormente. Asimismo, se hablará de Six Sigma como una de las teorías más populares que presenta el concepto de "Lean". Durante la presentación se incluirán varios ejemplos de técnicas de Lean Six Sigma aplicadas al testing. A diferencia de la mejora de procesos de pruebas con modelos de referencia como TMM, el uso de Lean Six Sigma empezará a mejorar con la investigación exhaustiva de los procesos propios de su empresa y mejorará a partir de este punto. Para ello, se contará con el respaldo de técnicas que le permiten mostrar inmediatamente el valor añadido para la organización. Esta presentación es especialmente interesante para los directores empresariales, gerentes de TI, gerentes de QA y gerentes de pruebas que están implicados en la mejora de la calidad de los procesos de gestión de pruebas.

Ponente(s): Iris Pinkster O'Riordain

Fecha: 18/11/2010

Entrega de los premios a las mejores ponencias y sorteo del partipante ganador

Entrega de los premios a las mejores ponencias: premio del Comité Técnico y premio de los participantes.

Los participantes que hayan votado para la mejor ponencia participarán en el sorteo de un iPad. 

Fecha: 18/11/2010

Automatización de las Pruebas Funcionales en SCRUM

La automatización de pruebas funcionales tiene un rol crucial para asegurar la calidad en aplicaciones que se desarrollan usando procesos ágiles como SCRUM. Las liberaciones intermedias en períodos cortos de tiempo requieren la ejecución de pruebas de regresión en forma más frecuente, resultando poco viable la ejecución manual de las mismas. A su vez, para que la automatización de las pruebas sea exitosa, la selección de los escenarios a automatizar se vuelve crítica, como también la planificación y la gestión de los artefactos generados.

En esta presentación se muestra como se incorporaron las actividades relacionadas a la automatización de pruebas funcionales al SCRUM team. Esta experiencia abarcó desde la estandarización del proceso de automatización, hasta la capacitación del equipo de testing en el uso de las tecnologías incorporadas. Se mostrará también como se automatizó parte del proceso de automatización en lo que se refiere a la generación de reportes de resultados.

Esta experiencia muestra que en los procesos ágiles también se puede planificar, aplicar buenas prácticas y a su vez, dar visibilidad del trabajo realizado por el equipo de testing a todos los actores.

Ponente(s): Claudia Badell

Fecha: 18/11/2010

Testing basado en modelos

El diseño de pruebas es una parte importante del testing de software, aunque requiere mucho tiempo. Existen muchas técnicas que se utilizan en la práctica. Sin embargo, el uso de técnicas oficiales no se implementa ampliamente en las organizaciones de hoy en día.

Se observa que los requisitos y el diseño del sistema fallan en los detalles y se ven sometidos a cambios frecuentes, y que el diseño de pruebas se inicia tarde en los proyectos de software; esto deriva en las consecuencias siguientes: 

• Detección tardía de omisiones de especificación (impacto negativo enorme en el lanzamiento al mercado)
• Alta probabilidad de errores humanos
• Resulta difícil demostrar la cobertura de pruebas
• Gasto elevado en el diseño de pruebas debido a la revisión del trabajo manual
• Se necesita un alto nivel de conocimiento de pruebas (diseño)

 

El enfoque de testing basado en modelos que se presenta en esta ponencia tiene el objetivo de ofrecer a los testers técnicas y herramientas para formalizar y anticipar el diseño de pruebas, a fin de eliminar algunas de estas limitaciones y reducir de manera significativa el esfuerzo invertido en el diseño de pruebas.

Las herramientas que se presentan ayudan a crear diseños de pruebas de fácil mantenimiento, crean casos de pruebas que están "listos para la automatización" y ayudan a los testers a ofrecer visibilidad de la cobertura de su diseño.

Ponente(s): Pilar Blanco

Fecha: 18/11/2010

Benchmark de calidad y pruebas: Mídete, toma conciencia y actúa

En esta sesión se presentan los resultados del estudio de mercado elaborado por Sopra Group en el que se ha medido en más de treinta compañías españolas el nivel de calidad de sus aplicaciones, junto con la madurez de sus procesos de pruebas.

Los datos del estudio responderán preguntas como:  

• ¿El desarrollo llevado a cabo en Factorías de Software se ha diferenciado por su calidad?
• ¿Se han constatado diferencias en compañías con equipos dedicados a pruebas?
• ¿Qué datos ha arrojado la antigüedad del software en la medición de su calidad?

 

La medición de los niveles de calidad del software y de la madurez de la función de pruebas ha aportado a estas compañías un conocimiento real de su situación y les ha ayudado a tomar conciencia de lo que verdaderamente necesitan, permitiéndoles establecer objetivos de mejora a corto y largo plazo.

Se expondrán casos de compañías que, tras una medición y toma de conciencia, han adoptado medidas en los aspectos más sensibles de su situación, alcanzando mejoras contrastadas y cuantificables, tales como la reducción del coste del mantenimiento en un 10%, el ahorro de 6.000 días/hombre en proyectos, o la reducción de errores en producción en un 40%.

Ponente(s): Luisa Morales

Fecha: 18/11/2010

¿Cómo demostrar ahorro de dinero con las pruebas de SW?

Normalmente, las actividades de testing de software se aceptan como algo positivo para la organización de TI que producen directamente un aumento de la calidad de los sistemas, aunque en muchos casos se consideran actividades costosas y redundantes.

El principal problema es que muy a menudo las actividades de gestión de pruebas no se respaldan con unos datos objetivos y cuantificables que demuestren las ventajas que estas actividades aportan al buen funcionamiento de los sistemas así como la cantidad de tiempo y dinero que ahorran en la organización de TI.

Ponente(s): Ignacio López Carrillo

Fecha: 18/11/2010

El debate ético sobre el testing de software

Un debate al estilo "House of Commons" sobre el tema "La ética en la profesión del testing". En esta sesión de sesenta minutos, se parte de unas afirmaciones estimulantes para garantizar un debate intenso que servirá para elevar la moral de los testers a lo más alto.

Este debate al estilo "House of Commons" se inspira en un programa de la televisión holandesa en que el objetivo es trasladar los temas cotidianos al salón de su casa de manera informativa y entretenida al mismo tiempo. Los organizadores se encargan de plantear las afirmaciones. Un organizador estará a favor de la afirmación y el otro en contra. El público tendrá la oportunidad de reaccionar ante las distintas alegaciones. Los organizadores animarán al público a que se pongan de su lado y argumentarán el punto de vista escogido.

A continuación se enumeran unos cuantos ejemplos sobre las afirmaciones que pueden plantearse:

• Se puede infringir la ley para conseguir los objetivos de las pruebas
• Siempre se debe decir la verdad
• Siempre se debe ser capaz de utilizar los datos sensibles de privacidad para realizar pruebas
• Como tester, no se debe tener un código de conducta profesional, ya que esto dificulta llevar a cabo un buen testing
• El testing y la ética son temas aparte

¿Será capaz de relajar sus principios y considerar qué podría pasar cuando uno actúa de manera no tan correcta? ¿Realmente son algunas de las afirmaciones tan opuestas? ¿Qué matices se deben aplicar? Comparta su opinión y quizás alcancemos un consenso sobre cuál es el "Código de conducta del tester".

Calificada como "Excelente" en la EuroSTAR 2009 (puntuación 9 en una escala del 1 al 10).

Ponente(s): Nathalie Rooseboom de Vries van Delft, Invitado sorpresa, Ewout van Driel

Fecha: 18/11/2010

Automatización de pruebas

La automatización de pruebas no incluye únicamente la automatización funcional. En esta presentación se realizará un paseo por las diferentes actividades de pruebas dando una visión de las posibilidades de automatización en las mismas.
También trataremos de argumentar, a favor o en contra algunos de los mitos sobre la automatización, presentando una visión diferente del proceso de automatización de pruebas.
Hablaremos sobre: El marco actual de las TIC, los tipos de pruebas más comunes, cómo encuadrar la automatización en las pruebas, cómo afrontar la automatización para que tenga éxito, mitos, realidades y conclusiones de la automatización

Ponente(s): Miguel Castaño

Fecha: 18/11/2010

Una reunión difícil...

Martes por la mañana, la hora punta ha sido una pesadilla y no has tenido tiempo suficiente para preparar lo imposible, una presentación que explique cómo testear una aplicación para conseguir una producción sin errores. Ya sabes cómo funciona: te identificas, vas a la sala de reuniones, conectas tu portátil y esperas a que la gente vaya llegando... Finalmente, diez minutos más tarde, te encuentras ante un nuevo cliente; es un gerente de la vieja escuela, siempre ha pensado que las cosas irán bien si asustas a los desarrolladores lo suficiente como para que trabajen 14 horas al día y entreguen código. Si el resultado no es bueno, añadiremos más hardware. Si los usuarios finales no están contentos con la herramienta siempre podemos contratar a otra empresa que siga con el desarrollo, y a lo mejor hasta podemos ahorrar dinero...

No se pierda a José y Álvaro en esta representación de papeles para saber cómo funcionan las reuniones de testing de software en la vida real.

Álvaro y José responderán a las preguntas y a las situaciones a las que se han tenido que enfrentar en algunas de las reuniones más difíciles por las que han pasado durante los últimos diez años como consultores, y veremos cómo las han superado con éxito.

Situaciones incluidas en la presentación:

- José ante "El director malvado"
- Álvaro ante "El Sr. CMMI"
- José ante "El director Lo-quiero-todo"
- Álvaro ante "El Sr. Automatización"

Ponente(s): José Aracil

Fecha: 18/11/2010

De la ausencia de procesos al nivel optimizado: del Nivel 1 al Nivel 5 de CMMI para QA en menos de cuatro años

Apostar por la sencillez. Esta es la filosofía de los testers de software que consiguieron que este CMMI de Nivel 1 a Nivel 5 fuese posible y repetible en menos de cinco años.

Observe y conozca las plantillas, los enfoques, las listas de comprobación, las métricas, el modelo de estimación para QA y otros documentos de apoyo que, una vez implementados y estandarizados, contribuyeron a que esta empresa elevara su organización del testing al Nivel 5 de CMMI en menos de cuatro años. El concepto de CMMI (Integración de Modelos de Madurez de Capacidades) se repasa levemente pero la atención no se centra en un modelo específico de mejora de procesos (CE, CMMI, IEEE, ISO, ITIL, OSA, SEI, etc.); en lugar de ello, esta presentación trata los procesos de testing que cubren la necesidad empresarial en primer lugar y, como extra añadido, derivan en un modelo de procesos de testing robusto merecedor del Nivel 5 de CMMI.

Muchas empresas invierten mucho tiempo y dinero en aplicar procesos, control y repetibilidad en su organización. Este enfoque abarca únicamente una parte de la organización, el grupo de pruebas. Además, se centra y desarrolla mediante los elementos que mejor funcionan para esta empresa en concreto.

En esta sesión aprenderá cómo progresar desde la ausencia de procesos hasta la obtención de los procesos robustos que le resulten eficaces.

Ponente(s): Jan Fish

Fecha: 18/11/2010

¿Validación ágil para dispositivos médicos?

En un entorno de dispositivos médicos, la validación de software viene impuesta por los organismos reguladores. Se espera que la validación "ofrezca un nivel de confianza de manera que la calidad del software sea apropiada para su uso en la sanidad pública" (FDA).

Para poder certificar que el software cumple su misión en la sanidad pública, el inspector debe saber qué hace el software, constatar que funciona adecuadamente y que no implica riesgos para la sanidad pública. En términos de software, esto significa: tener una descripción funcional del software, informes de procesos de pruebas y un informe de gestión de riesgos.
Así, la validación es un concepto amplio para los dispositivos médicos; representa la certeza de que el proceso de diseño, construcción y verificación del software está planificado y controlado.

¿Es necesaria una metodología de software específica? Existen estándares recomendados por los organismos reguladores, pero se acepta cualquier enfoque siempre que ofrezca al inspector lo que necesita. Según esto, se acepta el proceso ágil, con aquellos ajustes que permiten al fabricante ofrecer la documentación necesaria.

Existen principios en el enfoque ágil, como un mayor énfasis en la comunicación que en la documentación, en la productividad que en la fiabilidad, que pueden generar lagunas en los requisitos reguladores: estas lagunas se deben superar. Otros principios, como el testing continuo, las opiniones del cliente y la mejora están en total consonancia con el objetivo regulador de minimizar la inserción de defectos y maximizar la eliminación de defectos desde el principio.
Otras prácticas ágiles cumplen con las expectativas reguladoras, por ejemplo la propiedad individual y la responsabilidad sobre la calidad.

En resumen, un enfoque ágil que tiene en cuenta un ciclo de vida mejorado incluidos los planes y requisitos generales iniciales, las pruebas de aceptación finales, la limpieza de documentación y la producción controlada parece una buena opción, ya que cumple tanto con las necesidades empresariales de una adaptación rápida, fácil y rentable a los cambios como con los requisitos reguladores (los fabricantes de dispositivos médicos son parte del negocio).
La presentación se centrará en conceptos de validación amplios y la metodología ágil o los ajustes necesarios.

Ponente(s): Celestina Bianco