¿Es posible estandarizar las  pruebas de software?                    Junio 2012               Comisión de Calidad        ...
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 conju...
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 fu...
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 depruebas?   Disponer de     Un vocabulario común     Un proceso marco común    ...
¿A quién puede interesar?   Empresas u organizaciones   Organismos de regulación   Empresas u organizaciones auditadas ...
¿ Quién decide actualmente?   ¿Qué se prueba?   ¿Con qué profundidad?   ¿Qué NO se prueba?   ¿Cuánta prueba es suficie...
¿Cómo decidirlo?   Distinguiendo los niveles de decisión participantes                      Nivel organizacional         ...
Nivel organizacionalA modo de ejemplo                                                          Nivel de gestión de        ...
Nivel organizacionalNivel organizacional                              Nivel de gestión de                                 ...
Nivel organizacionalNivel organizacional en ejemplos:                        Nivel de gestión de                          ...
Nivel organizacionalNivel de gestión de proyectos                         Nivel de gestión de                             ...
Nivel organizacionalNivel de gestión de proyectos                           Nivel de gestión de                           ...
Nivel organizacionalNivel de gestión de proyectos   Nivel de gestión de                                    proyectosEjempl...
Nivel organizacionalNivel de ejecución de pruebas                   Nivel de gestión de                                   ...
Nivel organizacionalNivel de ejecución de pruebas                            Nivel de gestión de                          ...
Resumiendo:Niveles posibles de procesos de testing e interesados    Empresas /                                            ...
¿ZZZZZZZZZzzzzzzzzz……….?
EstructuraContenido de las PartesISO/IEC 29119
Overview of ISO/IEC 29119 Software Testing “The aim of ISO/IEC 29119 Software Testing is to     provide one definitive sta...
Estructura del estándar ISO 29119 en elaboración
ISO 29119 – Fundamentos y relaciones entre laspartes                               BS 7925-2                              ...
¿Qué reemplazará el nuevo estándar?
Parte 1: Conceptos y Vocabulario   Conceptos de prueba de software     Introducción     Relación entre prueba, desarrol...
Parte 2: Procesos de Testing   Comprenden los tres niveles indicados    previamente                   Organizational Test...
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 ...
Parte 4: Técnicas de prueba   Descripción y Ejemplos de utilización para:     Diseño de casos     Ejecución de las prue...
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 desar...
Assessment – Niveles propuestos                                                                      Optimizado    4 Mejor...
Assessment – Niveles propuestos    Nivel 0 - la organización no tiene definida una línea base para la actividad, por     ...
¿Cuándo estará disponible?Inicialmente prevista finalización                   • Parte 2 – Proceso de Testingdurante 2012 ...
¿Cuándo estará disponible? - Actualización 1Working Draft (WD)                                                   • Parte 2...
¿Cuándo estará disponible? - Actualización 2                                                                 A junio 2012 ...
… Finalmente …ALGUNAS CONCLUSIONES
¿Encararíamos alinearnos?• ¿Qué necesitaremos?   • Adecuar y difundir procesos   • Capacitar   • Eventualmente certificar ...
ISO/IEC 29119¿Qué fortalezas y debilidades encontramos?              Fortalezas                               DebilidadesE...
¿Qué le criticaríamos?   Visiones críticas:    Michael Bolton, James Bach y otros     http://www.pnsqc.org/2011-conferen...
¿Qué riesgos vemos?   Cambio de objetivos: cumplir con el estándar en    lugar de hacer buenas pruebas   Atención a los ...
Entonces … ¿UN estándar?¡Importante como compendio de       buenas prácticas!           Pero …   ¡NO convendría que fuera ...
Consideremos que …     ¡Todo el software que se construye necesita algún tipo de    prueba, que sea pensada,planificada y ...
Vistiendo a Cenicienta… en elaboración …                         Cinderella                         http://www.supercolori...
Links de interésOtros estándares o modelosMarcas registradasREFERENCIAS
Links de interés   http://softwaretestingstandard.org/   http://softwaretestingstandard.org/part1.php   http://software...
Otros estándares o modelos   BSI (1998a) BS 7925-1-1998, Software Testing –Vocabulary. BSI   BSI (1998b) BS 7925-2-1998,...
Otros estándares o modelos - cont   IEEE (2008) IEEE 829-2008, Standard for Software Test    Documentation. IEEE   ISO (...
Marcas registradas   Capability Maturity Model®, CMM®, SW-CMM®    and CMMI® are registered trademarks of the    Software ...
"Come to the dark side,… together we will rule the galaxy"
FIN                     ¡Gracias!                                   www.rmya.com.ar  www.qactions.com                     ...
Upcoming SlideShare
Loading in...5
×

Presentación cessi estandar iso iec 29119 2012 v1.0

1,090

Published on

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

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,090
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
47
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Presentación cessi estandar iso iec 29119 2012 v1.0

  1. 1. ¿Es posible estandarizar las pruebas de software? Junio 2012 Comisión de Calidad CESSI Alfonsina Morgavi – Pilar Barrio – Raúl Martínez
  2. 2. Vistiendo a Cenicienta Walt Disney – Cinderella – www.clipartdb.com
  3. 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. 4. Agenda Objetivos e introducción ISO/IEC 29119 Algunas conclusiones Referencias
  5. 5. OBJETIVOS E INTRODUCCIÓN
  6. 6. Objetivo Presentar el futuro estándar ISO/IEC 29119 Software Testing Debatir acerca de él, su importancia y su futuro
  7. 7. Sabemos que hoy existen estándares… ¡Parece importante mejorar esto!
  8. 8. Algunos estándares de testing actuales
  9. 9. Otros modelos relacionados con testing
  10. 10. ¿Cuál es el valor de tener UN estándar depruebas? 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. 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. 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. 13. ¿Cómo decidirlo? Distinguiendo los niveles de decisión participantes Nivel organizacional Nivel de gestión de proyectos Nivel de ejecución
  14. 14. Nivel organizacionalA 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. 15. Nivel organizacionalNivel 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. 16. Nivel organizacionalNivel organizacional en ejemplos: Nivel de gestión de proyectosPolí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. 17. Nivel organizacionalNivel 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. 18. Nivel organizacionalNivel 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. 19. Nivel organizacionalNivel de gestión de proyectos Nivel de gestión de proyectosEjemplo Nivel de ejecución P
  20. 20. Nivel organizacionalNivel 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. 21. Nivel organizacionalNivel de ejecución de pruebas Nivel de gestión de proyectosEjemplo Nivel de ejecución Ejecución Proyecto de pruebas Diseño Ejecución Ambientes Incidentes Avance Proceso Cierre de Resultados Ejecución
  22. 22. Resumiendo:Niveles posibles de procesos de testing e interesados Empresas / Organismosorganizaciones que regulaciónnecesitan garantías Proceso organizacional Auditores Empresas / internos y organizaciones externos auditadas Proceso de gestión de proyectos de pruebaProveedores de pruebas de Profesionales software de pruebas Procesos fundamentales de ejecución De pruebas De pruebas estáticas dinámicas
  23. 23. ¿ZZZZZZZZZzzzzzzzzz……….?
  24. 24. EstructuraContenido de las PartesISO/IEC 29119
  25. 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. 26. Estructura del estándar ISO 29119 en elaboración
  27. 27. ISO 29119 – Fundamentos y relaciones entre laspartes BS 7925-2 IEEE 1008 TPI ISO/IEC 15504-2 TMMi
  28. 28. ¿Qué reemplazará el nuevo estándar?
  29. 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. 30. Parte 2: Procesos de Testing Comprenden los tres niveles indicados previamente Organizational Test Process Test Management Processes Test M Fundamental Test Processes
  31. 31. Parte 2: Procesos de Testing A
  32. 32. Parte 3: Documentación  Define entregables a generar en relación a las pruebas  Anexo con templates y ejemplos de utilizaciónDocumentos siguen estructura definida en ISO/IEC 15289:2006Content of life-cycle information products.
  33. 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. 34. Parte 4: Técnicas basadas en estructura
  35. 35. Parte 4: Técnicas basadas en especificación
  36. 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. 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. 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. 39. ¿Cuándo estará disponible?Inicialmente prevista finalización • Parte 2 – Proceso de Testingdurante 2012 • Parte 3 – Documentación de TestingWorking Draft (WD)Committee Draft (CD) • Parte 1 - Conceptos y VocabularioFinal Committee Draft (FCD) • Parte 4 – Técnicas de TestingFinal Draft International Standard (FDIS)Final International Standard (FIS) http://softwaretestingstandard.org/projecttimeline.php
  40. 40. ¿Cuándo estará disponible? - Actualización 1Working Draft (WD) • Parte 2 – Proceso de TestingCommittee Draft (CD) • Parte 3 – Documentación de TestingFinal 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. 41. ¿Cuándo estará disponible? - Actualización 2 A junio 2012 http://softwaretestingstandard.org/projecttimeline.php
  42. 42. … Finalmente …ALGUNAS CONCLUSIONES
  43. 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. 44. ISO/IEC 29119¿Qué fortalezas y debilidades encontramos? Fortalezas DebilidadesEnfoque a riesgos No es novedosoTé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 burocraciaCompleta 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 culturalregulación de las pruebas y costos?
  45. 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. 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. 47. Entonces … ¿UN estándar?¡Importante como compendio de buenas prácticas! Pero … ¡NO convendría que fuera demasiado taxativo!
  48. 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. 49. Vistiendo a Cenicienta… en elaboración … Cinderella http://www.supercoloring.com/copyrights/
  50. 50. Links de interésOtros estándares o modelosMarcas registradasREFERENCIAS
  51. 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. 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. 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. 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. 55. "Come to the dark side,… together we will rule the galaxy"
  56. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×