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

¿Es posible estandarizar las pruebas de software?pruebas de software?

Noviembre 2011

3ª Jornada de Calidad de SoftwareCentro 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 ?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� 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 de pruebas?

� 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 ?� ¿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

A modo de ejemplo

� ¿Puede un líder de prueba definir todo esto?:qué probar, qué NO probar, con qué profundidad, cuánta prueba?

Utilidad Garantía

Nivel de gestión de

proyectos


Nivel de ejecución

Funcionali-dad del servicio

Capacidad y

Disponibi-lidad

Confiabi-lidad Soporte Continuidad Seguridad

Atributos de calidad

Nivel organizacional¿Qué define?

� La organización define de manera única y consensuada� Qué se prueba� Con qué profundidad

Qué NO se prueba


proyectos


Nivel de ejecución

� 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 organizacional en ejemplos:Política y estrategia de prueba

� 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


proyectos


Nivel de ejecución

� 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 de gestión de proyectos¿Por qué interesa?

� 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


proyectos


Nivel de ejecución

� ¿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 de gestión de proyectos ¿Quién decide?

� La organización define de manera única y consensuada

� Cómo se gestionan los proyectos de prueba� Cómo se informa el avance


proyectos


Nivel de ejecución

� 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 de gestión de proyectos Ejemplo


proyectos


Nivel de ejecución

P

Nivel de ejecución de pruebas¿Cómo se prueba?

� Define cómo:

� Se diseña e implementa� Se preparan los ambientes


proyectos


Nivel de ejecución

� Se ejecutan las pruebas� Se gestionan los incidentes

� Proponiendo técnicas y herramientas, y la documentación a generar

Nivel de ejecución de pruebas Ejemplo

Ejecución Proyecto de pruebas

Diseño


proyectos


Nivel de ejecución

Proceso

de

Ejecución

AmbientesEjecución

Incidentes

AvanceCierre

Resultados

Resumiendo:Niveles posibles de procesos de testing e interesad os

Proceso organizacional

Empresas / organizaciones que necesitan garantías

Auditores internos y externos

Organismos regulación

Empresas / organizaciones

auditadas

Proceso de gestión de proyectos de

prueba

externos auditadas

Procesos fundamentales de ejecución

Profesionales de pruebas

De pruebas

dinámicasDe pruebas estáticas

Proveedores de pruebas de

software

¿ZZZZZZZZZzzzzzzzzz……….?

ISO/IEC 29119

EstructuraContenido de las Partes

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 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 las partes

IEEE 1008

BS 7925-2

ISO/IEC 15504-2

TMMi

TPI

¿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� Enfoques de la prueba

� Vocabulario� BS 7925-1 Glossary of terms used in software testin g

(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&pageId=5439596

Parte 2: Procesos de Testing

� Comprenden los tres niveles indicados previamente

Organizational Test Process

Test MTest Management Processes

Organizational Test Process

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ón

Documentos siguen estructura definida en ISO/IEC 15289:2006 Content 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� 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 pr uebas: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

3

4 Mejora de procesos, actividades de calidad

completamente integradas en los proyectos

Acciones preventivas para la reducción de

riesgos en los proyectos

Assessment – Niveles propuestos

Reducción de riesgos

Optimizado

Actividad no definida

1

2

0

Pruebas básicas

Proceso proactivo para hacer

las pruebas más rentables

Costo-Efectividad

Inicial

Línea base

(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 � 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étricas

Ref: Self-Assessment Framework for Standard Test Process Model - Jussi Kasurinen, LUT

P

¿Cuándo estará disponible?

Working Draft (WD)Committee Draft (CD)Final Committee Draft (FCD)Final Draft International Standard (FDIS)Final International Standard (FIS)

• Parte 2 – Proceso de Testing• Parte 3 – Documentación de Testing• Parte 2 – Proceso de Testing• Parte 3 – Documentación de Testing

• Parte 1 - Conceptos y Vocabulario• Parte 4 – Técnicas de Testing• Parte 1 - Conceptos y Vocabulario• Parte 4 – Técnicas de Testing

Inicialmente prevista finalización durante 2012

http://softwaretestingstandard.org/projecttimeline.php

Working Draft (WD)Committee Draft (CD)Final Committee Draft (FCD)Final Draft International Standard (FDIS)Final International Standard (FIS)

• Parte 2 – Proceso de Testing• Parte 3 – Documentación de Testing• Parte 2 – Proceso de Testing• Parte 3 – Documentación de Testing

• Parte 1 - Conceptos y Vocabulario• Parte 4 – Técnicas de Testing• Parte 1 - Conceptos y Vocabulario• Parte 4 – Técnicas de Testing

¿Cuándo estará disponible? - Actualización

Actualmente estamos aquí

De: http://in2test.lsi.uniovi.es/gt26/presentations/ISO-29119-Javier-Tuya-AST-Seville-2011.pdf

Nov 2013

May 2014

ALGUNAS CONCLUSIONES… Finalmente …

• ¿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

¿Encararíamos alinearnos?

• 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 Debilidades

Enfoque a riesgos No es novedoso

Técnicas conocidas ¿Para grandes organizaciones ?

Refuerza confianza en el producto ¿Extensa y burocrática ?

La prueba “sube” a nivel organización -importancia

La prueba “sube” a nivel organización -burocracia

Completa vacíos de decisión No ser visto como “ágil”

Puede proveer una ventaja competitiva ¿Aplicable en cualquier contexto ?

Preparada para manejar complejidad y regulación de las pruebas

¿Excesiva adaptación , cambio cultural 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-� 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

¡Importante como compendio de buenas prácticas!

Entonces … ¿UN estándar?

¡NO convendría que fuera demasiado taxativo!

Pero …

¡Todo el software que se construye necesita algún tipo de

prueba, que sea pensada, planificada y ejecutada con alguna

Consideremos que …

planificada y ejecutada con alguna técnica !

NO es igual para todos los productos!

Pero …

Vistiendo a Cenicienta… en elaboración …

Cinderellahttp://www.supercoloring.com/copyrights/

Links de interés

REFERENCIAS

Links de interésOtros estándares o modelosMarcas registradas

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/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. 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 forSoftware 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 informationproducts (Documentation). ISO

� ISO (2010) ISO/IEC TR 24774, Guidelines for process description. ISO 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 � Test Maturity Model and TMM are the service marks of Illinois Institute of Technology.

� TMMi® is the registered trademark of the TMMiFoundation.

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

FIN

¡Gracias!¡Gracias!

www.rmya.com.ar

http://excelza.blogspot.com/

[email protected]

[email protected]

www.qactions.com

[email protected]

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

Technology

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