Webinar TestingUy - Cuando el testing no es opcional
•
0 recomendaciones•416 vistas
Expositor: Maximiliano Mannise ------------------------------------------- Resumen del webinar ------------------------------------------- Si bien en los tiempos que corren muchas empresas, sino ¿todas? … tienen en su día a día incorporadas las actividades de testing de software, hay sectores que desde siempre lo han tenido en cuenta y forma parte de sus procesos. Este sector agrupa un gran número de sistemas (HW/SW) y son conocidos como SCS (Safety-Critical Systems), sistemas que si fallan ponen en riesgo la vida humana, el medio ambiente o infraestructuras. Están presentes en nuestro día a día: automoción, medicina, aeroespacial, energía, transporte terrestre y marítimo entre otros. Como testers no siempre se nos da la oportunidad de abordar proyectos en estos sectores. En esta sesión les contaré mi experiencia personal en un proyecto de tren de alta velocidad (actividades de verificación y validación) y más recientemente en el sector médico: certificación de software sanitario para uso en Europa (marcado CE de producto sanitario). Veremos normativas vigentes, el enfoque tradicional de testing y cómo están irrumpiendo los métodos ágiles en el sector. Si te interesa conocer el testing en este tipo de proyectos, lo que hemos hecho y los desafíos que nos esperan, ¡no te pierdas esta sesión! ------------------------------------------- Acerca de Maximiliano Mannise ------------------------------------------- Maximiliano Mannise es Ingeniero en Computación de la Universidad Católica de Uruguay. Comenzó su carrera profesional en IBM Uruguay (1998), pasando por diferentes cargos y proyectos. En 2005 como Test Project Manager donde comienza su relación más directa con la disciplina de test. Actualmente se desempeña como Director de Software Quality en el Instituto Tecnológico de Informática (ITI) Valencia, España. Maximiliano ha participado en múltiples proyectos de calidad de software desde el 2005, en Uruguay, Argentina y desde 2007 en España. Es organizador de VLC Testing (www.vlctesting.es), el principal evento de testing en Valencia. Linkedin: https://www.linkedin.com/in/mmannise/ Twitter: https://twitter.com/mmannise
Recomendados
Recomendados
Más contenido relacionado
Similar a Webinar TestingUy - Cuando el testing no es opcional
Similar a Webinar TestingUy - Cuando el testing no es opcional (20)
Más de TestingUy
Más de TestingUy (20)
Último
Último (20)
Webinar TestingUy - Cuando el testing no es opcional
- 2. @mmannise SobreelITI… Investigación DesarrolloInnovación ServiciosAvanzadosenTIC Difusión Centro tecnológico dedicado a la Investigación, Desarrollo, Innovación y Prestación de servicios avanzados en Tecnologías de la Información y las Comunicaciones (TIC)
- 3. @mmannise SobreMi… Padre de familia Informático de profesión Ya tengo canas en la barba En testing … de casualidad (o no) Echando raíces en Valencia (Pero el corazón en el “paisito”)
- 4. @mmannise SobreMi…2020 Padre de familia Informático de profesión Ya tengo canas en la barba (pero no se ven) En testing … de casualidad (o no) Echando raíces en Valencia (Pero el corazón en el “paisito”)
- 7. @mmannise CALIDAD Y TEST DEL SOFTWARE
- 8. @mmannise Safety-CriticalSystems ▪ A safety-critical system (SCS) or life-critical system is a system whose failure or malfunction may result in one (or more) of the following outcomes: • Death or serious injury to people • Loss or severe damage to equipment/property • Environmental harm https://en.wikipedia.org/wiki/Safety-critical_system
- 10. @mmannise ¡NO ES OPCIONAL! SPICE Automotive UNE EN 50128 DO-178D IEC 62304 UNE EN 26262 ISO-14971 Marcado CE App Salud ISO-13485 IEC 61508
- 11. @mmannise SPICE Automotive UNE EN 50128 DO-178D UNE EN 26262 IEC 61508 ¡NO ES OPCIONAL!
- 12. @mmannise ¡NO ES OPCIONAL! SPICE Automotive DO-178D IEC 62304 UNE EN 26262 ISO-14971 Marcado CE App ISO-13485 IEC 61508 UNE EN 50128
- 15. @mmannise ModelodeDesarrolloenV Requisitos Arquitectura Diseño Test Integración Test Unitario Código Test. Sistemas
- 16. @mmannise ModelodeDesarrolloenV Requisitos Arquitectura Diseño Test Integración Test Unitario Código Test. Sistemas Certificación Externa (auditoría)
- 18. @mmannise Comunicación ▪ Resultados objetivos • Calidad código • Bugs • Cobertura test ▪ Evidencia • Resultado iteraciones de test • Trazabilidad ▪ Indicadores de calidad SW
- 19. @mmannise ProcesodeDecisión ▪ Criterios de aceptación • Cumple • No cumple ▪ Revisión de evidencias ▪ Análisis de riesgos
- 20. @mmannise Lomismodesiempre ▪ Personas • Perfiles específicos • Titulación ▪ Herramientas • Ciclo de vida completo • Certificadas ▪ Procesos (formales) • Verificación • Validación
- 21. @mmannise TipologíadeProyectos ▪ Grandes proyectos • Grandes presupuestos • Complejos • Circulo “cerrado” • Específicos del sector • Rail • Aeronáutica • Sector médico • Automoción • Energía ▪ Otros proyectos (Apps) • PyMEs • Tecnología accesible • Buenas ideas (wereables) • Start-up • Sectores principales • Medicina personalizada • Energía • Automoción*
- 24. @mmannise Sistemas en España ASFA (Anuncio de Señales y Frenado Automático) AVE (Alta Velocidad Española) G1 (Expo Sevilla), G2 ERTMS, G3 ERTMS
- 25. @mmannise Contexto:ASFA AnunciodeSeñalesyFrenadoAutomático http://www.ferropedia.es/wiki/ASFA ▪ ASFA clásico • 160 km/h* ▪ ASFA 200 • 200 km/h ▪ ASFA Digital
- 26. @mmannise Contexto:ERTMS EuropeanRailTrafficManagementSystem ▪ Nivel 1 • transpondedores pasivos (Eurobalizas) • 300 km/h ▪ Nivel 2 • GSM-R, RBC (Radio Block Center) • 350 km/h ▪ Nivel 3 • Localización activa • 500 km/h http://www.ferropedia.es/mediawiki/index.php/ERTMS http://www.ertms.net
- 32. @mmannise AlcancedelProyecto:ERTMSNivel2 European Vival Computer GSM Rail Driving Machine Interface Eurobalise Balise Transmission Module Sistemas de actuación Velocidad | frenado
- 33. @mmannise ¿Quiénesparticipan? Desarrollo Testing desarrollo Testing externo (VER & VAL) Auditorías Simulacros (VAL) Pruebas reales (VAL)
- 34. @mmannise Proyecto:Equipo ▪ 8 personas (+2 en picos) • 1 Director • 1 Jefe de proyecto • 6 Testers • Conocimiento de negocio • Perfiles técnicos • 2 Programadores/Arquitectos
- 35. @mmannise Proyecto:Herramientas ▪ Herramientas • Suite IBM Rational* • Repositorio documental • Repositorio de código SVN • Herramientas específicas SC • Herramientas análisis código • Herramientas Ad Hoc
- 36. @mmannise MétododeTrabajo:CASCADA(V)…pero Requisitos Arquitectura Diseño Test Integración Test Unitario Código Test. Sistemas
- 38. @mmannise MétododeTrabajo:Test ▪ Reunión semanal (lunes) • Interna • Indra ▪ Kanban • Backlog • Ciclo • Preparación (2d) • Especificación (5d) • Ejecución (2d) • Finalización (1d) • Terminados
- 39. @mmannise SafetyCritical:Contextotécnico Nivel SIL SIL 4 (1 fallo 100.000.000 horas) Lenguajes de programación MISRA C/C++ Sistemas redundantes 2oo3 (2 out of 3) Programación redundante Recursos limitados Componentes Desarrollos propios COTS Herramientas de V&V certificadas Evidencias Documentación Norma o industria
- 40. @mmannise HerramientasComerciales ▪ Restricciones • Verificada por uso • Certificada ▪ Análisis estático • MISRA C/C++ (320) • JSF C++ • Métricas de código ▪ Análisis dinámico ▪ Simuladores* ERTMS
- 41. @mmannise Herramientas(ADHOC) ▪ Generador de reportes • Resultados análisis estático • Resultado test manual • Resultado test automático ▪ BI Data Base ▪ Informes personalizados
- 42. @mmannise Herramientas(AdHoc) Código fuente Revisión de código • Guía de estilo • Reglas particulares Análisis estático Análisis Dinámico • Reglas de programación • Métricas de código • Extreme value analysis • Control Flow Analysis • Data Flow Analysis • Equivalence partitioning • Code coverage • Decision coverage • Unreachable code Evidencia Informe V&V ______ ______ ______ ______
- 44. @mmannise Herramientas(AdHoc) ▪ Simulador Validación • Condiciones de aceptación • Entrada de datos • ETCS DMI • (EU Train Control System - Driving Machine Interface) 88 Casos de Test Informe VAL* ______ ______ ______ ______
- 45. @mmannise OficinadeTest:SafetyCritical ▪ Verificación • Verificación de Código • Análisis Estático de Código • Análisis Dinámico de Código • Estándares de Codificación (MISRA C/C++) • Verificación funcional basada en requisitos (SRS) • Verificación de integración ▪ Validación • Basada en simuladores
- 46. @mmannise TécnicasdeTest<<>>Trazabilidad ▪ 50126 > 50128 (SW) • Particiones de Equivalencia • Valores límites • Cobertura de Grafos • Máquinas de Estado • Análisis estático de código • Análisis dinámico de código • Revisión documental • …
- 47. @mmannise Documentación (nuestrasentradas) ▪ Proyecto • Requisitos Hardware HRS • Requisitos Software SRS • Requisitos de Interfaz IRS • Requisitos de Seguridad SFY • Requisitos del Sistema ▪ ERA (EU Rail Agency) • ERTMS/ETCS Class 1 v230 • ALCATEL • ALSTOM • ANSALDO SIGNAL • BOMBARDIER • INVENSYS RAIL • SIEMENS • 20+ documentos (10MB) https://www.era.europa.eu/activities/european-rail-traffic-management-system-ertms_en
- 48. @mmannise DocumentaciónTest (nuestraevidencia) ▪ Basada en IEEE 829.2008 • Master Test Plan (MTP) • Level Test Plan (LTP) • Level Test Design (LTD) • Level Test Case (LTC) • Level Test Procedure (LTPr) • Level Test Log (LTL) • Anomaly Report (AR) • Level Interim Test Status Report (LITSR) • Level Test Report (LTR) • Master Test Report (MTR) https://es.wikipedia.org/wiki/IEEE_829 ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ______________ ____
- 51. @mmannise ProductoSanitario (afectaaunindividuo) ¿Es un programa informático? ¿Beneficia a pacientes individuales? ¿Genera o modifica datos? ¿Usado para apoyar o influir en la atención sanitaria individual? ¿Está diseñada para ayudar en el diagnóstico? ¿Sirve hacer seguimiento y apoyar un tratamiento? ¿Permite prevenir una enfermedad o recaída? http://ec.europa.eu/growth/sectors/medical-devices/index_en.htm MEDDEV 2.1/6
- 55. @mmannise ProductoSanitario (afectaaunindividuo) ¿Es un programa informático? ¿Beneficia a pacientes individuales? ¿Genera o modifica datos? ¿Usado para apoyar o influir en la atención sanitaria individual? ¿Está diseñada para ayudar en el diagnóstico? ¿Sirve hacer seguimiento y apoyar un tratamiento? ¿Permite prevenir una enfermedad o recaída? http://ec.europa.eu/growth/sectors/medical-devices/index_en.htm MEDDEV 2.1/6
- 57. @mmannise ClasificacióndelRiesgo Clase I Apps de bajo riesgo Clase IIa Apps de riesgo intermedio-bajo Clase IIb Apps de riesgo intermedio-alto Clase III Apps de riesgo alto
- 58. @mmannise Certificaciónsegúnelriesgo https://www.aemps.gob.es/productosSanitarios/organismoNotificado/home.htm Declaración CE de conformidad Auditoría Sistema Gestión Calidad Examen <<CE de tipo>> Necesita organismo notificado
- 60. @mmannise NormativaLegal (hacerlascosasbien) Sistema de Gestión de Calidad Ciclo de Vida del Software Gestión de Riesgos Evaluación y Seguimiento Clínico Vigilancia Post-Comercialización Ley Orgánica de Protección de Datos
- 61. @mmannise NormativaLegal (hacerlascosasbien) Sistema de Gestión de Calidad Ciclo de Vida del Software Gestión de Riesgos Evaluación y Seguimiento Clínico Vigilancia Post-Comercialización Ley Orgánica de Protección de Datos
- 62. @mmannise NormativaLegal (hacerlascosasbien) ISO 13.485 (ISO 9.001) UNE-EN 62.304 ISO 14.971 Evaluación y Seguimiento Clínico Vigilancia Post-Comercialización Ley Orgánica 15/199
- 63. @mmannise NormativaLegal (hacerlascosasbien) ISO 13.485 (ISO 9.001) UNE-EN 62.304 ISO 14.971 Evaluación y Seguimiento Clínico Vigilancia Post-Comercialización Ley Orgánica 15/199
- 64. @mmannise UNE-EN62.304:Clasificación Clase A No es posible lesión o daño para la salud Clase B Es posible LESION NO-SERIA Clase C Es posible muerte o LESION SERIA
- 65. @mmannise UNE-EN62.304:ClaseA Sistema de gestión de la calidad Proceso de gestión de riesgos Planificación del desarrollo Análisis de requisitos Implementación y verificación Liberación del software Proceso de mantenimiento Análisis de problemas y modificaciones Gestión de riesgos en los cambios Identificación de la configuración Control de cambios Resolución de problemas 12Procesos* 42Requisitos
- 66. @mmannise UNE-EN62.304:ClaseB Diseño arquitectónico Diseño detallado Integración Ensayos del sistema Liberación del software Análisis de problemas y modificaciones Identificación de riesgos Control de riesgos Verificación del control de riesgos Gestión de riesgos en los cambios 20Procesos* 88Requisitos
- 67. @mmannise UNE-EN62.304:ClaseC Idem clase B aumentan requisitos en: Planificación del desarrollo Diseño arquitectónico Diseño detallado Implementación y verificación 20Procesos* 94Requisitos
- 68. @mmannise Cierre
- 69. Milgracias