Workshop

    Testing
“fuera de la caja”

     Versión 2010
Testing – Por qué “fuera de la caja”?


   Pensemos sin prejuicios o ataduras
   Salgamos (los testers) de nuestra cajita
Agenda
Introducción – Primeras ideas


   Definamos en nuestros términos


                     Tester
                         ...
Introducción – Scrat, la ardilla



   Probemos a Scrat
Introducción – Qué descubrimos


   Trabajamos a ciegas si no conocemos:
      Nuestra misión
      Contexto del produc...
Belleza … y calidad…




         La Nación – Octubre 2009




    “Beauty (quality) is in the eyes of its beholder”
    ...
Conceptos básicos – Qué es CALIDAD


   Que el producto haga lo que dicen los folletos o la caja, y
    que el cliente lo...
Conceptos básicos –
Quiénes son los INTERESADOS


                               Cliente                Cliente /
        ...
Conceptos básicos – El contexto del producto




                      Características
                       del producto...
… un poco de humor…




         “Nuestra meta es escribir software
                 libre de defectos.
                  ...
Conceptos básicos – Qué es TESTING


   Una actividad empírica y/o investigación técnica
    para ver si el producto hace...
BUGs ??? ….


   Un caso real
1) Home Banking, busco movimientos entre fechas, presenta por defecto:




                ...
Conceptos básicos – Qué es un defecto


   Que el producto NO haga algo que dicen los
    folletos o la caja

   Que el ...
Nuestra misión

   El testing es un servicio

   Cuál es nuestra misión?
       Entender objetivos de interesados y con...
Nuestros objetivos

   El testing es un servicio

   Con qué objetivos trabajamos?
       Encontrar defectos importante...
Nuestros objetivos (2)

   El testing es un servicio

   Con qué objetivos trabajamos?
       Verificar interoperabilid...
Entrevista a candidato para tester


   Dada la misión y los objetivos del trabajo del
    tester, qué le pediríamos a un...
Nuestras habilidades

   Pensamiento crítico, reconocer errores y prejuicios

   Pensamiento analítico, ser detallista, ...
Nuestros derechos (como testers)

   Recibir buenas especificaciones y código
       Poder rechazar lo que no sirve
   ...
Nuestros problemas habituales


   Objeciones

   Preguntas que debemos saber contestar

   Los riesgos a mitigar

   ...
Las grandes objeciones

   No necesitamos probar / No somos la NASA
   No necesitamos probar a ese nivel de detalle
   ...
Las grandes preguntas

   Qué es la calidad?

   Para qué la necesitamos?

   Qué pasa si no la tenemos?

   Cómo la l...
Las siguientes preguntas

   Por qué probamos?

   Cómo probamos?

   Cuándo comenzamos a probar?

   Cuándo dejamos d...
Los riesgos que enfrentamos
   Desde la enfermedad de un integrante del proyecto…

   … Hasta una acción legal a la empr...
Y cómo los mitigamos o transferimos
   Implementación de Procesos definidos y Buenas Prácticas

   Incorporación tempran...
Cómo aportamos valor?

  1    Reducción del Costo Total

                                          Fallas en
             ...
Organización - QC en un Proyecto
         Analistas                                                            Sponsor


 ...
Organización - Interacción entre Grupos
                                                                        1    Plan ...
Organización – big picture
              Proveedor                                                        Cliente
        ...
El mapa completo de nuestras actividades…
 Alcance

                      Análisis y Modelado

                           ...
… y cómo organizamos nuestro trabajo…
Estrategias y Objetivos
   Estrategia: Visión integrada de:

       Técnicas reque...
Estrategia de prueba

                       Contexto del
                        Proyecto
                               ...
Seleccionar Técnicas de Testing adecuadas


   Según los posibles objetivos y riesgos, criterios de
    calidad y context...
Implementar Buenas Prácticas


   Lograr consenso sobre:

     Gestión  de cambios al proyecto
     Gestión  de configu...
Saber Informar


   Qué y a quiénes
     Calidad percibida
     Niveles de reportes
     Posibles acciones,
      o có...
Saber Informar – Ejemplo 1 - Defectos




                                        Paquete


                  Implementaci...
Saber Informar – Ejemplo 2 - Defectos
                                      Pocos Defectos
                   Muchos
     ...
Saber Informar – Ejemplo 3 –
Cobertura de la Prueba
Saber Informar – Ejemplo 4 –
Funcionalidad Completa
Saber Informar – Ejemplo 5 –
Funcionalidad Completa




                               Paquete


            Implementación
Saber Informar – Ejemplo 6 –
Nivel de Calidad
Saber Informar – Ejemplo 7 –
Avance
Conclusiones
   Tenemos que aportar valor: pronto, cuantificable,
    previniendo problemas, dando feedback.

   Tenemos...
Preguntas… Opiniones…




                 ¿?
FIN
  Muchas gracias

   www.rmya.com.ar

http://excelza.blogspot.com/

   pbarrio@rmya.com.ar
Upcoming SlideShare
Loading in …5
×

RMyA - workshop testing - v1.1

1,369 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
1,369
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
43
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

RMyA - workshop testing - v1.1

  1. 1. Workshop Testing “fuera de la caja” Versión 2010
  2. 2. Testing – Por qué “fuera de la caja”?  Pensemos sin prejuicios o ataduras  Salgamos (los testers) de nuestra cajita
  3. 3. Agenda
  4. 4. Introducción – Primeras ideas  Definamos en nuestros términos Tester Defecto Prueba Calidad Riesgo Requerimiento Testing Proceso
  5. 5. Introducción – Scrat, la ardilla  Probemos a Scrat
  6. 6. Introducción – Qué descubrimos  Trabajamos a ciegas si no conocemos:  Nuestra misión  Contexto del producto y el proyecto  Criterios de calidad de los diferentes interesados  Qué problema espera resolver el cliente? Y los distintos usuarios finales? Cuál es su expectativa?  Si trabajamos a ciegas, no podemos determinar una estrategia correcta, que ahorre costos y aporte valor  La calidad no es lo mismo para todos
  7. 7. Belleza … y calidad… La Nación – Octubre 2009  “Beauty (quality) is in the eyes of its beholder” - La belleza (calidad) está en los ojos del observador -
  8. 8. Conceptos básicos – Qué es CALIDAD  Que el producto haga lo que dicen los folletos o la caja, y que el cliente lo compre  Que al usuario le guste y le permita ser productivo en su trabajo  Cumplir los requisitos del cliente / de los interesados  Qué el cliente vuelva a comprar el producto, o lo recomiende a otros  ……
  9. 9. Conceptos básicos – Quiénes son los INTERESADOS Cliente Cliente / Usuario Líder de Sponsor Usuario Auditor Producto Líder de Proyecto Análisis Desarrollo Testing Tecnología Seguridad Operaciones
  10. 10. Conceptos básicos – El contexto del producto Características del producto Características Criterios de del proyecto Calidad
  11. 11. … un poco de humor… “Nuestra meta es escribir software libre de defectos.  “Viva! Sí, Sí! Somos ricos!!!” Les pagaré un bono de 10 dólares por cada defecto que encuentren y corrijan.” Dilbert – 1995
  12. 12. Conceptos básicos – Qué es TESTING  Una actividad empírica y/o investigación técnica para ver si el producto hace lo que dicen los folletos o la caja  Una forma de validar que el usuario pueda utilizarlo y ser productivo en su trabajo  Actividades orientadas a validar que se cumplen los requisitos del cliente  ……  Encontrar los defectos (“bugs”)
  13. 13. BUGs ??? ….  Un caso real 1) Home Banking, busco movimientos entre fechas, presenta por defecto: 2) Cambio a 01/09/2009, convierte a: 3) Al dar aceptar: 4) Invirtiendo una fecha, funciona … pero asume orden mes día:
  14. 14. Conceptos básicos – Qué es un defecto  Que el producto NO haga algo que dicen los folletos o la caja  Que el usuario NO pueda cumplir con su actividad parcial o totalmente  Que NO se cumpla algún requisito del cliente  ……  Un defecto tiene que importar / afectar a alguien, no sólo al tester
  15. 15. Nuestra misión  El testing es un servicio  Cuál es nuestra misión?  Entender objetivos de interesados y contexto del producto  Identificar criterios de calidad aplicables  Cuestionar y evaluar el producto  Focalizar los riesgos, entender los cambios  Investigar, explorar, proveer feedback  Confirmar, comunicar  Aportar valor al proceso de construcción sugiriendo mejoras  Cuál es nuestro rol?  Proveer a la gerencia información sobre la calidad  Siendo críticos con el producto y el proceso  Para permitir decisiones informadas
  16. 16. Nuestros objetivos  El testing es un servicio  Con qué objetivos trabajamos?  Encontrar defectos importantes  Lograr que se corrijan los defectos más importantes  Ayudar a clientes y usuarios a identificar y explicitar los criterios de calidad  Evaluar la calidad del producto  Ayudar a la gerencia a determinar posibilidades de release  Impedir releases prematuros  Ayudar a predecir y controlar costos de mantenimiento
  17. 17. Nuestros objetivos (2)  El testing es un servicio  Con qué objetivos trabajamos?  Verificar interoperabilidad con otros productos  Identificar escenarios de uso seguros  Verificar cumplimiento de especificaciones  Certificar cumplimiento de un estándar determinado  Asegurar que el proceso de prueba sigue estándares  Minimizar el riesgo de acciones legales (cliente no satisfecho, multas de un organismo de control…)  Evaluar producto para una tercera parte ……..
  18. 18. Entrevista a candidato para tester  Dada la misión y los objetivos del trabajo del tester, qué le pediríamos a un candidato en una entrevista laboral?
  19. 19. Nuestras habilidades  Pensamiento crítico, reconocer errores y prejuicios  Pensamiento analítico, ser detallista, pero no perderse en detalles (las hormigas y los elefantes)  Pensamiento sistemático, enfrentar la complejidad  Pensamiento basado en contexto, enfrentar situaciones cambiantes, entender qué ocurre en el proyecto y en la organización  Pensamiento científico, diseñar y ejecutar experimentos  Habilidades cognitivas, aprender y observar, en general, y sobre el negocio y el proceso  Habilidades de comunicación, informar (CUIDADO, somos los mensajeros)  Programación, deseable, algunos testers
  20. 20. Nuestros derechos (como testers)  Recibir buenas especificaciones y código  Poder rechazar lo que no sirve  Tener una misión clara  Consensuada con los interesados  Opinar sobre el plan de trabajo  Participar en la planificación  Identificar riesgos y formas de mitigarlos  Contar con tiempo y recursos  Integrados al equipo de trabajo  Distribuida la carga de trabajo en el tiempo  Opinar sobre la calidad  En forma fundamentada y en base a evidencias  Qué pasa si salimos hoy?
  21. 21. Nuestros problemas habituales  Objeciones  Preguntas que debemos saber contestar  Los riesgos a mitigar  Cómo organizarnos para aportar valor Identifican objeciones típicas ? Identifican preguntas típicas ?
  22. 22. Las grandes objeciones  No necesitamos probar / No somos la NASA  No necesitamos probar a ese nivel de detalle  Cuesta mucho / Lleva mucho tiempo  No termina nunca / No tenemos tiempo / No está en el plan  Puede encontrar muchos problemas / Quedaremos mal  No podremos entregar en fecha / Demoraremos la salida del producto  El testing no aporta valor / A nadie le preocupan los defectos  Prueban los desarrolladores / Saben lo que hacen / Tienen mucha experiencia  Los testers nunca encuentran lo importante  No tenemos tiempo de especificar los requerimientos PERO …  Querríamos volar en un avión cuyo software no ha sido probado?
  23. 23. Las grandes preguntas  Qué es la calidad?  Para qué la necesitamos?  Qué pasa si no la tenemos?  Cómo la logramos?  Cuánto cuesta?  Es para nosotros?
  24. 24. Las siguientes preguntas  Por qué probamos?  Cómo probamos?  Cuándo comenzamos a probar?  Cuándo dejamos de probar?  Qué probamos?  Con qué probamos?  Hemos probado todo?  Podemos hacerlo mejor?
  25. 25. Los riesgos que enfrentamos  Desde la enfermedad de un integrante del proyecto…  … Hasta una acción legal a la empresa si el producto falla… y otros…  Pasando por:  Alcance o requerimientos indefinidos  Requerimientos conflictivos / cambiantes  Factores de éxito desconocidos  Calendarios y/o presupuestos irreales  Problemas de comunicación en el proyecto  Usuarios no involucrados / no comprometidos / problemas políticos  Nueva tecnología / poco conocimiento / falta de recursos capacitados  Pruebas inadecuadas  Complejidad  Dependencia de proveedores externos  No se valora el esfuerzo del equipo de testing, no se ve como algo útil, o se quiere evitar que los problemas se hagan visibles  …………
  26. 26. Y cómo los mitigamos o transferimos  Implementación de Procesos definidos y Buenas Prácticas  Incorporación temprana de los usuarios en los proyectos, pruebas de aceptación  Organización de Áreas de QA / QC  Equipos de Prueba en un Proyecto / Prueba en todo el ciclo de vida  Planificación de las pruebas  Capacitación a los recursos  Incorporación de Herramientas  Registración y Seguimiento de Defectos  Administración de Ciclos, Condiciones y Casos de Prueba  Métricas / Indicadores  Automatización  Administración de Cambios / Requerimientos / Configuración  Outsourcing / Tercerización
  27. 27. Cómo aportamos valor? 1 Reducción del Costo Total Fallas en Producción 2 Mejor Calidad - Mejor Imagen Ahorro Facilita el 3 Control de Proyectos Fallas Producción Fallas en Aceptación Fallas Aceptación 4 Facilita la Integración Verificaciones Ayuda a la Aplicación del 5 y Pruebas Proceso Verificaciones y Pruebas Ayuda a la Administración 6 de la Configuración Prevención Prevención (Plan Calidad, procesos) 7 Facilita la Capacitación Perfil de Costos sin QC Perfil de Costos con QC
  28. 28. Organización - QC en un Proyecto Analistas Sponsor Defectos Administración Interfaces Casos de Prueba Proyecto Líder Desarrolladores Proyecto Analistas Testers Plan de Pruebas Informe de Estado de Calidad Proyección de Tiempos Producto Customs listo para QC Probar Desarrolladores QC Manager Producto listo para Aceptar Líderes Funcionales Usuarios Parametrización Usuarios Funcionales Usuarios Ambiente de Desarrollo Ambiente de QC Ambiente de Aceptación
  29. 29. Organización - Interacción entre Grupos 1 Plan de Pruebas Informe de Estado de Calidad Líder de 9 Proyección de Tiempos Proyecto Especificación Funcional 2 Especificación Técnica Producto listo para aceptar QC 10 Informe de entrega Equipo de Desarrollo Usuarios Producto listo para probar 4 Informe de entrega 5 7 3 Defecto nuevo Defecto cerrado Condiciones de Prueba o reabierto Casos de Prueba Ciclos de Prueba Base Datos Base Datos 6 Defecto corregido Casos de Defectos Prueba 8 Indicadores
  30. 30. Organización – big picture Proveedor Cliente Desarrollo Evidencia Defectos Prueba Casos de Prueba Líder Proveedor Testers Testers Funcionales Producto Producto Equipo listo para Equipo aprobado Homologación para Desarrollo Homologar Instalar en Producción Analistas Desarrolladores QC Manager Usuarios Centro de Desarrollo Sponsor Plan de Prueba Informe de Estado de Calidad Proyección de Tiempos Administración Ambiente de Desarrollo Proyecto Líder Proyecto Ambiente de Ambiente de QC Homologación
  31. 31. El mapa completo de nuestras actividades… Alcance Análisis y Modelado Diseño y Desarrollo Testing Aceptación Implementación y Liberación Verificación Validación • Revisión Requerimientos • Revisión Diseño Funcional • Revisión Diseño Técnico • Pruebas Unitarias (desarrollo) • Revisión Código • Prueba Funcionales • Pruebas de Usabilidad • Pruebas de Integración • Pruebas No Funcionales • Defectos (performance, etc) Testers • Casos de Prueba •Pruebas de Aceptación (usuario) • Automatización Herramientas QC • Plan de Pruebas • Análisis de Evolución de la Prueba (comportamiento de defectos) Manager • Análisis de Cobertura de la Prueba (comportamiento de ciclos y casos de prueba) • Comparación de métricas entre Proyectos Planificación y Control de la Prueba
  32. 32. … y cómo organizamos nuestro trabajo… Estrategias y Objetivos  Estrategia: Visión integrada de:  Técnicas requeridas para lograr el objetivo.  Logística y recursos materiales necesarios durante el proyecto.  Soporte y recursos humanos necesarios durante el proyecto.  En qué basarnos?  Información sobre los objetivos del testing para los distintos interesados.  En qué influyen?  Gestión y políticas del proyecto.  Información a proveer a los distintos interesados.
  33. 33. Estrategia de prueba Contexto del Proyecto • Diversificación • Costos vs Valor • Habilidades • Experiencia Pruebas Criterios de Características Calidad del Producto Calidad percibida
  34. 34. Seleccionar Técnicas de Testing adecuadas  Según los posibles objetivos y riesgos, criterios de calidad y contexto, diferentes técnicas:  Testing funcional  Testing basado en especificaciones  Domain Testing  Risk Based Testing  Testing de escenarios  Testing de regresión  Testing de stress  Testing exploratorio  Testing de compatibilidad (por ej., de impresión)  Testing (automatizado) de volúmenes  Testing de usabilidad  Testing de accesibilidad  ……..
  35. 35. Implementar Buenas Prácticas  Lograr consenso sobre:  Gestión de cambios al proyecto  Gestión de configuraciones  Necesidad de Ambientes y su administración  Builds frecuentes  Registración y seguimiento de defectos  Priorización de corrección / triage de defectos  Criterios de aceptación  Calidad necesaria / aceptable para el producto  Participación de usuarios / pruebas de aceptación  ……..
  36. 36. Saber Informar  Qué y a quiénes  Calidad percibida  Niveles de reportes  Posibles acciones, o cómo intentamos corregir el rumbo  Cuándo  Reuniones de avance internas (testing)  Reuniones de avance del equipo de proyecto  Reuniones con otros interesados / sponsor  Métricas  Qué “contar”: defectos, casos de prueba, cobertura…  Cómo interpretar los números  Uniformidad
  37. 37. Saber Informar – Ejemplo 1 - Defectos Paquete Implementación
  38. 38. Saber Informar – Ejemplo 2 - Defectos Pocos Defectos Muchos Pendientes Defectos Pendientes Permite identificar tendencias, en qué momento se prevé terminar con la prueba o con la corrección De lo pendiente, cuál es el estado y su impacto.
  39. 39. Saber Informar – Ejemplo 3 – Cobertura de la Prueba
  40. 40. Saber Informar – Ejemplo 4 – Funcionalidad Completa
  41. 41. Saber Informar – Ejemplo 5 – Funcionalidad Completa Paquete Implementación
  42. 42. Saber Informar – Ejemplo 6 – Nivel de Calidad
  43. 43. Saber Informar – Ejemplo 7 – Avance
  44. 44. Conclusiones  Tenemos que aportar valor: pronto, cuantificable, previniendo problemas, dando feedback.  Tenemos que trabajar en equipo, ser confiables y eficientes  No somos “ciudadanos de segunda”  Tampoco somos los “guardianes” de la calidad  Necesitamos capacitarnos y ganar experiencia  Podemos mejorar nuestros procesos (y ayudar a mejorar los demás procesos)  …Otras conclusiones?
  45. 45. Preguntas… Opiniones… ¿?
  46. 46. FIN Muchas gracias www.rmya.com.ar http://excelza.blogspot.com/ pbarrio@rmya.com.ar

×