presentación cessi estandar iso iec 29119 2012 v1.0
DESCRIPTION
Presentación ofrecida en CESSI en Junio 2012 acerca del estandar ISO 29119 sobre pruebas de software. Actualizado a la fecha.TRANSCRIPT
¿Es posible estandarizar las
pruebas de software?
Junio 2012
Comisión de Calidad
CESSI
Alfonsina Morgavi – Pilar Barrio – Raúl Martínez
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
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
¿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?
¿Quién pone la vara de calidad?
¿Cómo decidirlo?
Distinguiendo los niveles de decisión participantes
Nivel de gestión de proyectos
Nivel organizacional
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
Funcionali-dad del servicio
Garantía
Capacidad
y
Disponibi-lidad
Confiabi-lidad
Soporte Continuidad Seguridad
Atributos de calidad
Nivel de gestión de
proyectos
Nivel organizacional
Nivel de ejecución
Nivel organizacional
¿Qué define?
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 de gestión de
proyectos
Nivel organizacional
Nivel de ejecució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
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
Nivel organizacional
Nivel de ejecución
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
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
Nivel organizacional
Nivel de ejecución
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
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
Nivel organizacional
Nivel de ejecución
Nivel de gestión de proyectos
Ejemplo
Nivel de gestión de
proyectos
Nivel organizacional
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
Se ejecutan las pruebas
Se gestionan los incidentes
Proponiendo técnicas y herramientas, y la
documentación a generar
Nivel de gestión de
proyectos
Nivel organizacional
Nivel de ejecución
Nivel de ejecución de pruebas
Ejemplo
Proceso
de
Ejecución
Ejecución Proyecto de pruebas
Diseño
Ambientes Ejecución
Incidentes
Avance Cierre
Resultados
Nivel de gestión de
proyectos
Nivel organizacional
Nivel de ejecución
Resumiendo: Niveles posibles de procesos de testing e interesados
Proceso de gestión de proyectos de
prueba
Proceso organizacional
Empresas /
organizaciones que
necesitan garantías
Auditores
internos y
externos
Organismos
regulación
Empresas /
organizaciones
auditadas
Procesos fundamentales de ejecución
Profesionales
de pruebas
De pruebas
dinámicas De pruebas estáticas
Proveedores de
pruebas de
software
¿ZZZZZZZZZzzzzzzzzz……….?
ISO/IEC 29119
Estructura
Contenido 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
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
IEEE 1008
BS 7925-2
ISO 29119 – Fundamentos y relaciones entre las
partes
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
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
Test M Test 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
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
Actividad no definida
3
4
1
2
0
Pruebas básicas
Mejora de procesos, actividades de calidad completamente integradas en los proyectos
Proceso proactivo para hacer las pruebas más rentables
Acciones preventivas para la reducción de riesgos en los proyectos
Assessment – Niveles propuestos
Reducción de riesgos
Optimizado
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 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 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 1 - Conceptos y Vocabulario
• Parte 4 – Técnicas de Testing
¿Cuándo estará disponible? - Actualización 1
De: http://in2test.lsi.uniovi.es/gt26/presentations/ISO-29119-Javier-Tuya-AST-Seville-2011.pdf
A noviembre 2011
Nov 2013
May 2014
¿Cuándo estará disponible? - Actualización 2
A junio 2012
http://softwaretestingstandard.org/projecttimeline.php
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 • ¿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
¿Encararíamos alinearnos?
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-
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
técnica!
Consideremos que …
¡NO es igual para todos los
productos!
Pero …
Vistiendo a Cenicienta
… en elaboración …
Cinderella
http://www.supercoloring.com/copyrights/
REFERENCIAS
Links de interés
Otros estándares o modelos
Marcas 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/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
ISO/IEC 25000:2005, Software Engineering – Software Product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE
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
http://excelza.blogspot.com/
www.qactions.com