Presentación ofrecida en CESSI en Junio 2012 acerca del estandar ISO 29119 sobre pruebas de software. Actualizado a la fecha.

1. ¿Es posible estandarizar las
pruebas de software?
Junio 2012
Comisión de Calidad
CESSI
Alfonsina Morgavi – Pilar Barrio – Raúl Martínez

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

3. 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?

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

5. OBJETIVOS E INTRODUCCIÓN

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

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

8. Algunos estándares de testing actuales

9. Otros modelos relacionados con testing

10. ¿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

11. ¿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

12. ¿ 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?

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

14. Nivel organizacional
A 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

15. Nivel organizacional
Nivel 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

16. Nivel organizacional
Nivel organizacional en ejemplos: Nivel de gestión de
proyectos
Polí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 ….”

17. Nivel organizacional
Nivel 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?

18. Nivel organizacional
Nivel 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

19. Nivel organizacional
Nivel de gestión de proyectos Nivel de gestión de
proyectos
Ejemplo Nivel de ejecución
P

20. Nivel organizacional
Nivel 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

21. Nivel organizacional
Nivel de ejecución de pruebas Nivel de gestión de
proyectos
Ejemplo Nivel de ejecución
Ejecución Proyecto de pruebas
Diseño
Ejecución
Ambientes
Incidentes
Avance Proceso
Cierre de
Resultados Ejecución

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

23. ¿ZZZZZZZZZzzzzzzzzz……….?

24. Estructura
Contenido de las Partes
ISO/IEC 29119

25. 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/

26. Estructura del estándar ISO 29119 en elaboración

27. ISO 29119 – Fundamentos y relaciones entre las
partes
BS 7925-2
IEEE 1008
TPI
ISO/IEC
15504-2
TMMi

28. ¿Qué reemplazará el nuevo estándar?

29. 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

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

31. Parte 2: Procesos de Testing
A

32. 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.

33. 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

34. Parte 4: Técnicas basadas en estructura

35. Parte 4: Técnicas basadas en especificación

36. 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

37. 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)

38. 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

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

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

41. ¿Cuándo estará disponible? - Actualización 2
A junio 2012
http://softwaretestingstandard.org/projecttimeline.php

42. … Finalmente …
ALGUNAS CONCLUSIONES

43. ¿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

44. 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 - La prueba “sube” a nivel organización -
importancia 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 ¿Excesiva adaptación, cambio cultural
regulación de las pruebas y costos?

45. ¿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 …

46. ¿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

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

48. 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!

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

50. Links de interés
Otros estándares o modelos
Marcas registradas
REFERENCIAS

51. 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/

52. 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

53. 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.

54. 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.

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

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