¿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
Top Related