RMyA - Presentación Jornada ORT Estandar ISO IEC 29119 - 2011 v1.0

¿Es posible estandarizar las pruebas de software? Noviembre 2011 3ª Jornada de Calidad de Software Centro de Tecnología ORT Alfonsina Morgavi – Pilar Barrio – Raúl Martínez

Vistiendo a Cenicienta Walt Disney – Cinderella – www.clipartdb.com

Las grandes preguntas Dada la diversidad de software que actualmente se construye, ¿Es posible definir un conjunto de buenas prácticas de pruebas de software que se adecúe a cualquier organización, proyecto y producto? ¿Quién aplicaría ese conjunto de buenas prácticas? ¿Para qué se aplicaría? Ya existen estándares y modelos, ¿para qué uno nuevo?

Agenda Objetivos e introducción ISO/IEC 29119 Algunas conclusiones Referencias

OBJETIVOS E INTRODUCCIÓN P

Objetivo Presentar el futuro estándar ISO/IEC 29119 Software Testing Debatir acerca de él, su importancia y su futuro

Sabemos que hoy existen estándares… ¡Parece importante mejorar esto!

Algunos estándares de testing actuales

Otros modelos relacionados con testing R

¿Cuál es el valor de tener UN estándar depruebas? Disponer de Un vocabulario común Un proceso marco común Un conjunto de documentación recomendada Poder establecer Una guía sobre técnicas de prueba recomendadas Un proceso de evaluación del estado de la práctica

¿A quién puede interesar? Empresas u organizaciones Organismos de regulación Empresas u organizaciones auditadas o controladas Proveedores de pruebas de software Auditores internos o externos Profesionales de pruebas, especialmente líderes de proyectos y de práctica

¿ Quién decide actualmente? ¿Qué se prueba? ¿Con qué profundidad? ¿Qué NO se prueba? ¿Cuánta prueba es suficiente? ¿Quién pone la vara de calidad?

¿Cómo decidirlo? Distinguiendo los niveles de decisión participantes Nivel organizacional Nivel de gestión de proyectos Nivel de ejecución

Nivel organizacionalA modo de ejemplo Nivel de gestión de proyectos Nivel de ejecución ¿Puede un líder de prueba definir todo esto?: qué probar, qué NO probar, con qué profundidad, cuánta prueba? Utilidad Garantía Capacidad Funcionali- y Confiabi- dad del lidad Soporte Continuidad Seguridad servicio Disponibi- lidad Atributos de calidad

Nivel organizacionalNivel organizacional Nivel de gestión de proyectos¿Qué define? Nivel de ejecución La organización define de manera única y consensuada Qué se prueba Con qué profundidad Qué NO se prueba Según la criticidad de su software y el nivel de riesgo que la organización quiera asumir QUÉ, no CÓMO: UNA política breve UNA estrategia de mayor extensión

Nivel organizacionalNivel organizacional en ejemplos: Nivel de gestión de proyectosPolítica y estrategia de prueba Nivel de ejecución Política: “Todos nuestros productos deben ser probados según los lineamientos de calidad de producto del estándar ISO/IEC 25000” Estrategia: “Se planificará la prueba de productos teniendo en cuenta su perfil de riesgo o criticidad: - Para productos de perfil de riesgo Alto, las pruebas del sistema deben lograr un objetivo del 95% de cobertura funcional y se deben evaluar cinco características de calidad no funcionales: seguridad, confiabilidad, portabilidad, …; - para productos de perfil de riesgo ….”

Nivel organizacionalNivel de gestión de proyectos Nivel de gestión de proyectos¿Por qué interesa? Nivel de ejecución Para poder contestar: ¿Cómo administramos los proyectos de prueba? ¿Qué información de performance de la prueba generamos? ¿Se cumplieron los objetivos de calidad para dar por terminada la prueba? ¿Quién decide esto hoy? ¿Cuándo? ¿Se brinda la misma información de seguimiento y control para todos los proyectos de prueba?

Nivel organizacionalNivel de gestión de proyectos Nivel de gestión de proyectos¿Quién decide? Nivel de ejecución La organización define de manera única y consensuada Cómo se gestionan los proyectos de prueba Cómo se informa el avance Cómo se evalúan y controlan los riesgos Cuándo se da por concluida la prueba Qué contiene un plan de testing, general y particular

Nivel organizacionalNivel de gestión de proyectos Nivel de gestión de proyectosEjemplo Nivel de ejecución P

Nivel organizacionalNivel de ejecución de pruebas Nivel de gestión de proyectos¿Cómo se prueba? Nivel de ejecución Define cómo: Se diseña e implementa Se preparan los ambientes Se ejecutan las pruebas Se gestionan los incidentes Proponiendo técnicas y herramientas, y la documentación a generar

Nivel organizacionalNivel de ejecución de pruebas Nivel de gestión de proyectosEjemplo Nivel de ejecución Ejecución Proyecto de pruebas Diseño Ejecución Ambientes Incidentes Avance Proceso Cierre de Resultados Ejecución

Resumiendo:Niveles posibles de procesos de testing e interesados Empresas / Organismosorganizaciones que regulaciónnecesitan garantías Proceso organizacional Auditores Empresas / internos y organizaciones externos auditadas Proceso de gestión de proyectos de pruebaProveedores de pruebas de Profesionales software de pruebas Procesos fundamentales de ejecución De pruebas De pruebas estáticas dinámicas

¿ZZZZZZZZZzzzzzzzzz……….?

EstructuraContenido de las PartesISO/IEC 29119

Overview of ISO/IEC 29119 Software Testing “The aim of ISO/IEC 29119 Software Testing is to provide one definitive standard that captures vocabulary, processes, documentation and techniques for the entire software testing lifecycle. From organisational test strategies and test policies, project and phase test strategies and plans, to test case analysis, design, execution, reporting and beyond, this standard will support testing on any software development or maintenance project.” http://softwaretestingstandard.org/

Estructura del estándar ISO 29119 en elaboración

ISO 29119 – Fundamentos y relaciones entre laspartes BS 7925-2 IEEE 1008 TPI ISO/IEC 15504-2 TMMi

¿Qué reemplazará el nuevo estándar?

Parte 1: Conceptos y Vocabulario Conceptos de prueba de software Introducción Relación entre prueba, desarrollo y mantenimiento Implicancias de los modelos de ciclo de vida Enfoques de la prueba Vocabulario BS 7925-1 Glossary of terms used in software testing (British Standards Institute) http://www.testingstandards.co.uk/bs_7925-1.htm Inicialmente los que aparecen también en ISTQB Standard glossary of terms used in Software Testing (International Software Testing Qualifications Board) http://istqb.org/pages/worddav/preview.action?fileName=ISTQB+Glossary+of+Testing+Terms+2+1.pdf&pag eId=5439596

Parte 2: Procesos de Testing Comprenden los tres niveles indicados previamente Organizational Test Process Test Management Processes Test M Fundamental Test Processes

Parte 2: Procesos de Testing A

Parte 3: Documentación Define entregables a generar en relación a las pruebas Anexo con templates y ejemplos de utilizaciónDocumentos siguen estructura definida en ISO/IEC 15289:2006Content of life-cycle information products.

Parte 4: Técnicas de prueba Descripción y Ejemplos de utilización para: Diseño de casos Ejecución de las pruebas Medición de sus resultados Según plan específico, qué técnicas aplicar Para Pruebas Dinámicas Técnicas de Pruebas Estáticas no incluidas todavía Para Medición Para características de calidad (no funcionales) Enfoque mandatorio de gestión y ejecución de las pruebas: que estén basadas en riesgos Pero NO aparece RBT cómo técnica actualmente

Parte 4: Técnicas basadas en estructura

Parte 4: Técnicas basadas en especificación

Parte 5: Assessment Evaluación del proceso de prueba No formaba parte del estándar inicial propuesto Aún en desarrollo: En conjunto por dos grupos de trabajo, WG26 y WG10 (Process Assessment WG) Actualmente llamada ISO/IEC 33063 Se estima que se publicará también como ISO/IEC 29119-5 Cinco niveles de madurez propuestos, en forma similar a otros modelos de madurez

Assessment – Niveles propuestos Optimizado 4 Mejora de procesos, actividades de calidad completamente integradas en los proyectos Acciones preventivas para la reducción de Reducción de riesgos 3 riesgos en los proyectos Costo-Efectividad Proceso proactivo para hacer 2 las pruebas más rentables Línea base Pruebas básicas 1 Inicial Actividad no definida 0 (Según propuesta de Jussi Kasurinen, LUT)

Assessment – Niveles propuestos Nivel 0 - la organización no tiene definida una línea base para la actividad, por cuanto la misma no es medible Nivel 1 - la organización ha documentado, y generado acuerdos respecto de la metodología para realizar las pruebas básicas, designando los recursos para su realización Nivel 2 - la organización realiza un esfuerzo sistemático para hacer rentable y eficiente la detección de problemas en el software Nivel 3 - la organización está preparada para actuar sobre efectos no deseados, aplica medidas y toma acciones preventivas tempranamente para bajar los riesgos para el proyecto Nivel 4 - las actividades de QA y de QC se realizan de forma integrada con el proyecto de desarrollo. Las actividades de prueba se mantienen y mejoran basadas en la política de calidad, las necesidades y las métricasRef: Self-Assessment Framework for Standard Test Process Model - Jussi Kasurinen, LUT P

¿Cuándo estará disponible?Inicialmente prevista finalización durante 2012 • Parte 2 – Proceso de Testing • Parte 3 – Documentación de TestingWorking Draft (WD)Committee Draft (CD)Final Committee Draft (FCD) • Parte 1 - Conceptos y VocabularioFinal Draft International Standard (FDIS) • Parte 4 – Técnicas de TestingFinal International Standard (FIS) http://softwaretestingstandard.org/projecttimeline.php

¿Cuándo estará disponible? - ActualizaciónWorking Draft (WD) • Parte 2 – Proceso de TestingCommittee Draft (CD) • Parte 3 – Documentación de TestingFinal Committee Draft (FCD)Final Draft International Standard (FDIS)Final International Standard (FIS) • Parte 1 - Conceptos y Vocabulario • Parte 4 – Técnicas de Testing Actualmente estamos aquí Nov 2013 May 2014 De: http://in2test.lsi.uniovi.es/gt26/presentations/ISO-29119-Javier-Tuya-AST-Seville-2011.pdf

… Finalmente …ALGUNAS CONCLUSIONES

¿Encararíamos alinearnos?• ¿Qué necesitaremos? • Adecuar y difundir procesos • Capacitar • Eventualmente certificar y recertificar • El Estándar y Herramientas de apoyo• ¿ Cuánto nos costará? • Costos de lo anterior • Costo de QA• ¿Qué beneficios nos dará? • Interoperabilidad y consistencia • Vocabulario común y claridad en SLAs • Mejora de procesos y Benchmarking• ¿ A qué será aplicable? • A todos los dominios, regulados o no • A todos los modelos de ciclo de vida y fases • A sistemas de información y embebidos

ISO/IEC 29119¿Qué fortalezas y debilidades encontramos? Fortalezas DebilidadesEnfoque a riesgos No es novedosoTécnicas conocidas ¿Para grandes organizaciones?Refuerza confianza en el producto ¿Extensa y burocrática?La prueba “sube” a nivel organización - La prueba “sube” a nivel organización -importancia burocraciaCompleta vacíos de decisión No ser visto como “ágil”Puede proveer una ventaja competitiva ¿Aplicable en cualquier contexto?Preparada para manejar complejidad y ¿Excesiva adaptación, cambio culturalregulación de las pruebas y costos?

¿Qué le criticaríamos? Visiones críticas: Michael Bolton, James Bach y otros http://www.pnsqc.org/2011-conference/invited- speakers#Bolton http://sqa.stackexchange.com/questions/750/will-the- new-iso-iec-29119-software-testing-standard-work-with- agile-methodologi Y otras seguramente …

¿Qué riesgos vemos? Cambio de objetivos: cumplir con el estándar en lugar de hacer buenas pruebas Atención a los artefactos y no al producto Obsolescencia del estándar Regulación vs creatividad, investigación e innovación

Entonces … ¿UN estándar?¡Importante como compendio de buenas prácticas! Pero … ¡NO convendría que fuera demasiado taxativo!

Consideremos que … ¡Todo el software que se construye necesita algún tipo de prueba, que sea pensada,planificada y ejecutada con alguna técnica! Pero … NO es igual para todos los productos!

Vistiendo a Cenicienta… en elaboración … Cinderella http://www.supercoloring.com/copyrights/

Links de interésOtros estándares o modelosMarcas registradasREFERENCIAS

Links de interés http://softwaretestingstandard.org/ http://softwaretestingstandard.org/part1.php http://softwaretestingstandard.org/part2.php http://softwaretestingstandard.org/part3.php http://softwaretestingstandard.org/part4.php http://softwaretestingstandard.org/aboutWG26.php http://testing-solutions.com/iso-29119-shaping-the-future-of- the-industry-or-just-more-theoretical-shelfware http://istqb.org Proyecto ESPA: http://www.soberit.hut.fi/espa/ Sub-proyecto MASTO: http://www2.it.lut.fi/project/MASTO/

Otros estándares o modelos BSI (1998a) BS 7925-1-1998, Software Testing – Vocabulary. BSI BSI (1998b) BS 7925-2-1998, Software Component Testing. BSI CENELEC (2001) EN 50128-2001: Railway Applications - Software for railway control and protection systems. CENELEC IEC (1998) IEC 61508:1998, Functional safety of electrical/electronic/programmable electronic safety-related systems. IEC IEEE (2003) IEEE 1008-1987(R2003), Standard for Software Unit Testing. IEEE

Otros estándares o modelos - cont IEEE (2008) IEEE 829-2008, Standard for Software Test Documentation. IEEE ISO (2006) ISO/IEC 15289:2006, Content of life-cycle information products (Documentation). ISO ISO (2010) ISO/IEC TR 24774, Guidelines for process description. ISO MISRA (1994) Development Guidelines for Vehicle Based Software. MISRA MOD (1997) Def Stan 00-55: Requirements for safety-related software in defence equipment. Issue 2. Ministry of Defence RTCA (1992) DO-178B Software Considerations in Airborne Systems and Equipment Certification. RTCA Inc.

Marcas registradas Capability Maturity Model®, CMM®, SW-CMM® and CMMI® are registered trademarks of the Software Engineering Institute and Carnegie Mellon University. Test Maturity Model and TMM are the service marks of Illinois Institute of Technology. TMMi® is the registered trademark of the TMMi Foundation.

"Come to the dark side,… together we will rule the galaxy"

FIN ¡Gracias! www.rmya.com.ar www.qactions.com http://excelza.blogspot.com/amorgavi@qactions.com pbarrio@rmya.com.ar rmartinez@rmya.com.ar

RMyA - Presentación Jornada ORT Estandar ISO IEC 29119 - 2011 v1.0

by Pilar Barrio

Accessibility

Categories

Upload Details

Usage Rights

Statistics