¿es posible estandarizar las pruebas de software?...¿es posible estandarizar las pruebas de...
TRANSCRIPT
¿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 organizacional
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
Nivel de gestión de
proyectos
Nivel organizacional
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
Nivel de gestión de
proyectos
Nivel organizacional
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
Nivel de gestión de
proyectos
Nivel organizacional
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
Nivel de gestión de
proyectos
Nivel organizacional
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
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
Nivel de gestión de
proyectos
Nivel organizacional
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
Nivel de gestión de
proyectos
Nivel organizacional
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/
www.qactions.com