VV&T and QA software departments in a medical company

1. VV&T and QA software departments in a medical company Antonio Robres – Diagnostic Grifols, S.A. 28-10-2010

2. Presentación Introducción Departamento de VV&T Departamento de gestión de la calidad de software Resultados Acciones futuras Indice

3. Empresa dentro del holding Grifols S.A. Sector farmacéutico. Principal actividad: Diseño, fabricación y comercialización de instrumentos y reactivos para diagnóstico in-vitro. 250 trabajadores (100 en departamentos de I+D) Presente en los 5 continentes. Actividad de Diagnostic Grifols S.A.

4. Porque crear un departamento de calidad? Sector en pleno crecimiento Fuertes marcos regulatorios USA: 21 CFR 820, 21 C. FR 11, FDA Guidances Europa, Japón, Canadá, etc.: ISO 13485:2003 + requisitos locales Normas GMP Utilización de nuevas tecnologías para los nuevos productos. Necesidad de disminuir el tiempo de desarrollo. Necesidad de disminuir los errores en producción Mucho más costosos de arreglar. Dañan la imagen de la empresa Introducción

5. Conclusión Calidad y eficacia en I+D Creación de dos departamentos independientes del departamento de desarrollo Departamento de Calidad de Software Departamento de Validación y Verificación de Software (VV&T) Inversión en herramientas para la gestión de la calidad durante todo el ciclo de vida del desarrollo del producto. Introducción

6. Departamento de VV&T • Grupo independiente del desarrollo de software. • Integrado por 5/7 personas • Jefe del departamento • 2 Analistas de test • 2 Ingenieros de test • 2 becarios a tiempo parcial (ocasionalmente) • Presentes en todo el ciclo de vida del proyecto • Especificaciones • Diseño • Implementación

7. Funciones departamento de VV&T • Revisión de especificaciones / requisitos. • Validación de test unitario y estudio de coberturas de código. • Test de integración. • Diseño y ejecución Test de sistema. • Diseño y ejecución del test de regresión y Smoke test. • Test exploratorio. • Registro de incidencias detectadas durante las actividades de test. • Verificación de las incidencias resueltas. • Automatización de pruebas.

8. Unit & Integration Test • Unit Test • Validación de los Unit Test realizados por los departamentos de desarrollo. • Realización de Unit Test independientemente del equipo de desarrollo. • Integration Test: • Diseñados para probar la integración entre dos o más componentes del sistema. • Pruebas realizadas mediante JUnit a partir de las los tests unitarios realizados anteriormente. • Utilización de Drivers y Stubs para su implementación.

9. Se realiza el cálculo de las coberturas de código mediante dos métodos: Test unitarios o de integración realizados por desarrollo. Ejecución de los tests de sistema y/o Smoke Test mediante módulos instrumentalizados. Se realizan para los módulos realizados en Java o C. Java: Cobertura y/o EclEmma C: Bullseye Se obtienen diversas métricas de cobertura Line coverage Branch coverage Complexity Coberturas

10. System Test • Test funcionales exhaustivos sobre una parte específica del software. • Diseño • Se diseñan a partir de las especificaciones de software. • Se revisan cada vez que se cambian las especificaciones del software. • Ejecución: • Se ejecuta de forma periódica antes de la salida de una release “major” a producción. • La ejecución se realiza por una persona diferente al que lo ha diseñado. • Se realiza un registro de los resultados y se abren los “bugs” encontrados durante su ejecución.

11. Test de funcionalidades básicas de la aplicación. Se realiza una revisión en cada “release” del software. Duración de un día (ejecución manual). Se ejecuta antes de realizar los System test para evitar un re-testing. Verifica que no se hayan creado errores en los componentes básicos del software durante las nuevas implementaciones. Smoke Test

12. Realización de pruebas de forma aleatoria sin documentación (o documentación no finalizada) como primera toma de contacto con el software del sistema. Se realizan antes del System Test. Primera toma de contacto con las nuevas funcionalidades en las nuevas versiones. Facilita el diseño de los casos de prueba y el aprendizaje de las nuevas funcionalidades. Pueden encontrarse fallos no contemplados dentro de los System Test. Test Exploratorio

13. Ciclo de vida de errores • El equipo de test se encuentra dentro del ciclo de vida de los errores en varias fases: • Fase test: Registra en el sistema los errores encontrados de la forma más específica y concreta posible. • Se indica el procedimiento para reproducir el error • Se indica el comportamiento esperado según las especificaciones • Se adjuntan los logs y screenshots necesarios. • Verificación: Se verifica cada uno de los errores resueltos en la versión.

14. Departamento de SQA • Grupo independiente del desarrollo de software. • Integrado por 4 personas • Jefe del departamento • 3 Ingenieros de calidad • Presentes en todo el ciclo de vida del proyecto • Especificaciones • Diseño • Implementación

15. Responsables de las herramientas de gestión de la configuración Repositorio de código Gestor de errores Gestión de requisitos Diseño y despliegue de los entornos de desarrollo, test, y producción Auditorías de código Gestión de versiones Revisión de especificaciones y diseño Sistema de integración Continua Obtención de métricas de desarrollo Release Notes Funciones departamento de SQA

16. Herramienta de gestión de código Se encargan de la correcta utilización de la herramienta (repositorio de software) Gestión de etiquetas y versiones Realizan training y soporte de las herramientas a los usuarios en caso necesario. Herramienta de gestión de errores Verifican el cumplimiento de las normas de introducción de errores por parte de los usuarios Seguimiento del ciclo de vida de los errores introducidos Herramienta de gestión de requisitos Realización de plantillas de los documentos de requisitos. Gestión de documentos Herramientas de Gestión

17. Definen los diferentes entornos de los proyectos: Desarrollo Test Producción Mantienen y realizan un seguimiento de los diferentes entornos de los proyectos Se encargan de configurar los sistemas necesarios para el desarrollo y la ejecución del software Herramientas de desarrollo de código (Java, C++, Flex…) BBDD SO Dan soporte a los entornos definidos Definición de entornos

18. Periódicamente se realizan por el departamento de SQA auditorias/revisiones de código: Se comprueba el cumplimiento de las diferentes normas establecidas para los lenguajes de programación utilizados MISRA Java Code Conventions Se validan varios factores del código realizado por desarrollo: Sintaxis Dead code Compilaciones correctas Código duplicado Comentarios Utilización de herramientas para realizar las auditorias. Auditorias de código

19. Integración Continua

20. Beneficios Detección rápida de software no compilable. Detección de fallos en los tests unitarios. Comprobación de la integración de los módulos. Detección de los fallos de los tests de integración. Obtención de una versión estable cada día. Análisis de código diario. Herramientas Open Source como servidor de integración continua. Integración Continua

21. Metricas • Obtenidas por sistema de integración continua (ver imagen). • Métricas tests funcionales o de sistema: • # CRs implementados • # CRs verificados • # New bugs • # Reopen CRs

22. Diseño y ejecución de los tests de sistema de todos los módulos del proyecto. Más de 1200 errores encontrados mediante los tests de sistema y test exploratorio. Diseño y ejecución del smoke test en cada versión beta. Estudio de coberturas mediante tests unitarios y ejecución de los test de sistemas (instrumentalización de código). Verificación de más de 1300 errores encontrados previamente Verificación de nuevas funcionalidades implementadas. Mejora de la calidad del código mediante la introducción de reglas MISRA y Java code coventions. Despliegue del servidor de integración continua Framework completo desde requerimientos hasta la fase de test con total trazabilidad. Automatización de proyectos pequeños. Resultados

23. Resultados

24. Herramienta de gestión de test Automatización de tests Test no funcionales Aplicación de metodologías ágiles Acciones Futuras

25. Objetivos: Gestión dinámica de los protocolos de los tests de sistema. Plantillas de pruebas comunes para todos los proyectos Histórico de ejecuciones para cada uno de los entornos. Introducción de resultados de los tests ejecutados manualmente Versionado de test cases Integración con herramienta de requisitos para tener una completa trazabilidad. Ejecución programada de los tests automatizados. Reporting. Herramienta de gestión de Test

26. Despliegue de herramientas para la automatización de tests de sistema y de regresión. Varias tecnologías implicadas Java Flex C++ Integración: Herramienta de gestión de test: obtención de trazabilidad Entorno de desarrollo Propósito: Creación de una API común a todos los proyectos Posibilidad de ejecución sin intervención humana Uso de simuladores Automatización

27. Diseño y implementación de pruebas no funcionales Seguridad Rendimiento Stress Usabilidad Recovery Carga continua Test no funcional

28. Implementación de metodologías ágiles en el ciclo de vida del software: SCRUM Equipo de test presente durante el planning de cada sprint y meeting diario. Sprint cada 2 – 4 semanas. Al finalizar un sprint se realizan las pruebas específicas y de regresión. Los errores detectados se añaden a la lista de backlock y se priorizan dentro del sprint correspondiente. Metodologías ágiles

29. Obtención de un software operativo e incremental en cada versión Realización de los tests en cada sprint Detección temprana de fallos Errores críticos detectados antes. Los equipos de desarrollo y test saben la evolución de sus compañeros y de los dos departamentos Mayor comunicación entre departamentos Mayor implicación en el proyecto Ventajas

30. arobres@grifols.com Preguntas