Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Argentesting 2016 - Pruebas manuales o automaticas

354 views

Published on

por Marcelo Dalceggio.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Argentesting 2016 - Pruebas manuales o automaticas

  1. 1. Pruebas manuales o automáticas …. ¿qué decidimos? MARCELO DALCEGGIO
  2. 2. Vamos a charlar sobre …  Testing en la Facultad  Automatización: ¿estamos listos?  Información que debemos conocer antes de decidir  Peleando con el Business Case  Lecciones aprendidas
  3. 3. “ ” Testing is the process of executing a program with the intent of finding errors THE ART OF SOFTWARE TESTING 1ST EDITION BY MYERS, GLENFORD J. (1979)
  4. 4. Eficacia  Descubrir la mayor cantidad de fallas  Encontrar las más importantes  Evitar reportar fallas que en realidad no lo son …
  5. 5. Eficiencia  Ejecutar las pruebas …  lo más rápido,  afectando la menor cantidad de recursos y  con el mínimo esfuerzo/costo … que se pueda para cumplir con el objetivo
  6. 6. Alcance: Pruebas Funcionales y …  Performance  Volumen  Stress  Tolerancia a Fallas  Portabilidad  Usabilidad  Seguridad  Recuperabilidad  Compliance  … … …
  7. 7. … to automate or not to automate …  ¿Qué, cuándo y cómo comenzar a pensar en automatizar?  ¿Qué variables debiéramos tener en cuenta?  ¿Podremos justificar el … “gasto” … o … “inversión”?
  8. 8. Antes de arrancar  Tener muy claro la madurez de mi “testing manual”  ¿Cuánto tiempo llevo testeando?  ¿Tengo un proceso definido?  ¿Funciona? ¿Estoy conforme? ¿Lo reviso y lo mejoro?  ¿Poseo historia? ¿Guardé métricas?  Q de ciclos / Esfuerzo incurrido / Ventana de tiempo / Costos
  9. 9. Antes de arrancar  ¿Capitalicé las “lessons learned”?  Resguardo mis activos?  Conocimiento  Condiciones & Casos de Prueba  Evidencias  Incidentes
  10. 10. A tener en cuenta ( I ): Objetivo  Lo primero:  Identificar la motivación  Expectativas  ¿Cuál es mi driver?  Umbral de Calidad – Not “Good Enough”  Mas profundidad / Mas cobertura / Mas repeticiones / Troubleshooting  Costo  Ventana de tiempo  Equipo  ¿Son varios?  ¿Tengo restricciones?  ¿Tengo flexibilidad?  Recordar que nos van a medir por ésto!
  11. 11. A tener en cuenta ( II ): La aplicación  Criticidad del producto / aplicación  Relevancia para el negocio  ¿Producto maduro/estable?  “Volatilidad” de cambios  ¿Qué parte de la aplicación es la que más cambia?  Rol de la interfaz de usuario  Frecuencia del testing de regresión  Importancia de los Reqs No Funcionales
  12. 12. A tener en cuenta ( II ): La aplicación  Desarrollo In House / Third party Dev / COTS  ¿Tecnología propietaria?  Plataformas: OS / DB / Browsers / Devices / Integración / Cloud / …  ¿Una o varias?  Frecuencia de upgrades de las partes
  13. 13. A tener en cuenta ( III ): El SDLC  Ciclo de vida  ¿Basado en prácticas ágiles o mas formales?  Calidad de las entregas  Relacionamiento DEV  TEST
  14. 14. A tener en cuenta ( IV ): El contexto  Cultura equipos  Skill demandado / Disponibilidad / Valor  Recursos económicos  Urgencias
  15. 15. A tener en cuenta ( V ): La herramienta A la hora de pensar en una alternativa:  Evolución de versiones  Soporte  Conocimiento  Esfuerzo de Scripting & Lenguaje  Productividad  Mantenibilidad del Scripting (“survive change”)  Acompañañamiento de las versiones / Compatibilidad  ¿Podré acompañar? Si necesito o si no necesito …  ¿Comprar o desarrollar? / ¿Comerciales o gratuitas?
  16. 16. Desafío: El Business Case  La presión por el ROI  Lo usual: Ahorro en esfuerzo = Ahorro en dinero  De la Prueba Manual:  Costo del Diseño/Construcción de Condiciones & Casos de prueba  Costo de un Ciclo de Prueba  De la Prueba Automática:  Licencias Herramienta + HW + SW de Base + Training + Mantenimiento  Costo de Diseño/Construcción de Scripts  Costo de prueba de los scripts / Change Mgmt & Versionado / BackUp / Etc …..  Costo de un Ciclo de Prueba  Por costo tener en cuenta esfuerzo y $$$
  17. 17. Desafío: El Business Case  Y lo que el ROI no mide:  Rapidez en la ejecución  Detección temprana de fallas  Mayor cobertura  Time to Market  Incremento de periodicidad  Además de los temas relacionados con los equipos  ¿Y cuándo de otra manera no es posible?  La automatización como soporte y liberar recursos (NO reemplazar)  Nueva funcionalidad (crecimiento) = Mayor ejecución  Visión del “Costo/Beneficio”
  18. 18. Lecciones Aprendidas  Acumular experiencia en testing manual  Setear expectativas (automatizar es una manera de ejecutar!)  No esperar resultados de manera inmediata  No pretender automatizar todo  No creer que solo se automatiza lo manual  No perder vista que las condiciones y casos son el activo  La automatización por si sola no encuentra fallas  Independizarse lo más posible de una herramienta en particular  Separar el equipo de automatización del equipo de ejecución  Contar con los perfiles adecuados para automatizar
  19. 19. Lecciones Aprendidas  Analizar proyecto a proyecto  Cada situación es particular  Esperar cualquier evaluación de automatizar a contar con un producto/aplicación con cierta estabilidad  Cuidado con la volatilidad de la interfaz de usuario  Automatizar es un proyecto mas y su entregable es una aplicación mas  Y como toda aplicación queremos que sea mantenible (… y demás atributos de calidad …)  Mas todo lo que ya conocemos de cualquier desarrollo …  Automatizar debe seguir un proceso  Medir & Evaluar
  20. 20. Entonces … o ¿… PREGUNTAS …?

×