Este documento discute los beneficios y desafíos de la automatización de pruebas de software. Menciona que la automatización puede mejorar la calidad, el rendimiento y la productividad al hacer que las máquinas realicen tareas de prueba de forma repetitiva. Sin embargo, también señala que la automatización no reemplaza la necesidad de pruebas manuales y que la calidad de las pruebas automatizadas depende de factores como la selección de casos de prueba, los datos y los oráculos utilizados. El documento pro

1. Ing. Federico Toledo ftoledo@abstracta.com.uy Testing automatizadoHagamos que las máquinas trabajen por nosotros

2. Discusión de “salados” “Test automationissimplyanautomaticway of doingwhattestersweredoingbefore” Steve Rowe (Tester at Microsoft) “Test automationmeansextendingthereach of testers” James Batch (TesterConsultant at Satisfice)

3. Introducción Testing de Regresión Verificar que el Software no tenga regresiones ¿Solo revisar bugs? Hay quienes dicen que es un chequeo Michael Bolton http://www.developsense.com/2009/08/testing-vs-checking.html

4. Testing de Regresión Aburrido Siempre lo mismo Error humano

5. Automatización Adquirir tecnología para automatizar procesos manuales Mejora: calidad performance en la producción rendimiento de los recursos humanos

6. Dificultades/desafíos

7. metAs Plantear objetivos de la automatización Ejemplos Integración continua: ejecutar pruebas todas las noches Suite de prueba para ejecutar ante cada release Pruebas de humo Evitar que lleguen ciertos bugs al cliente

8. casos de prUeba Selección basada en Riesgo Importancia para el negocio Costo de un bug Impacto Vidas/dinero en juego Selección basada en uso Las más usadas, las más importantes

9. casos de prUeba Si ya tenemos casos documentados Si no tenemos – automatizar es formalizar las pruebas en cierto lenguaje (ejecutable) Comenzar simple Línea amarilla – según uso, etc.

10. herramienTa Hay muchas herramientas muy buenas Enfoque tradicional no compatible con GeneXus GXtest Crear rápido Evolucionar y mantener fácil

11. Mismo nivel de abstracción Transacción Clientes Herramientas tradicionales GXtest herramienTa

12. datOs Se varían con estructuras asociadas a los test cases automatizados Datapools Invocaciones a ProcGX

13. aMbientes Ambientes KB Aplicación Generada Artefactos de prueba Datos de prueba Datos en la base ¿Backups de bases de datos? Resultados

14. orAculos Veredicto si una prueba pasa o falla Modelo mental Acciones de validación A nivel de respuestas A nivel de datos ProcGX

15. ¿cuándo ejecuTar? Planificar Automatización Mantenimiento Ejecuciones Verificación y Reporte de bugs Correcciones de bugs detectados

16. ¿quIén? ¿Equipo de automatización? La riqueza está en la variedad Desarrollador Tester Usuario La variedad se da en Selección Datos Oráculos

17. ¿quIén?

18. ¿quIén? Compromiso como con un producto Desarrolladores Testers Gerencia

19. mOtivación Necesidad de las personas a sentir que están aportando algo al proyecto. Se pierde este sentimiento al volver a hacer lo que ya se hizo Ejecutando pruebas de regresión Corrigiendo scripts automatizados

20. mOtivación Como tester siento que estoy aportando Si obtengo resultados antes Si encuentro bugs más temprano Si doy mejor información sobre el estado de la aplicación ¿Estamos listos para salir al mercado?

21. consideracioNes1 - ¿Qué hago con un bug? Ser efectivo Minimizar secuencia de pasos Ser preciso Objetivo

22. consideracioNes2 - ¿Cuándo se hacen visibles los resultados? ¿Cada vez que encuentro un bug? ¿Cada vez que las ejecuto? Desde que las pienso.

23. ¿Se encuentran más bugs? NO SI

24. ¡Ojo! Riesgo No confiarse en que tengo pruebas automatizadas Mil casos de prueba no significan nada Calidad de los casos de prueba

25. coNsideraciones Siempre se ejecuta lo mismo No remplaza ni minimiza el Testing manual Agregamos un componente al equipo Un tester virtual Trabaja de noche, muy rápido Siempre hace lo que se le indicó sin equivocarse No piensa, no se da cuenta de otras cosas que no se le dijo que revise

26. Checking A – metas / objetivos U – casos de prueba T – herramienta O – datos de prueba M – ambientes A – oráculos T – ¿cuándo? planificar I – ¿quién? compromiso O – motivación N – consideraciones pass

27. Primer beta del producto presentada hace un año Sale a la venta en setiembre de 2009 Utilizada por K2b Grupo Fenix Concepto DLyA Accendo

28. ¿Preguntas? Gracias! www.abstracta.com.uy gxtest.abstracta.com.uy/wiki abstracta-soft.blogspot.com Ing. Federico Toledo ftoledo@abstracta.com.uy