Este documento describe los conceptos y enfoques de la automatización de pruebas de software, incluyendo las pruebas progresivas y regresivas, los costos y beneficios de la automatización, y los enfoques como Data Driven Testing y Keyword Driven Testing. Explica que la automatización reduce el trabajo repetitivo y mejora la consistencia, pero requiere inversión inicial, y que el enfoque de Keyword Driven Testing facilita el desarrollo de pruebas para los equipos de prueba.

1. Capitalizando la automatización de la
prueba sin programar
AARÓN MORENO MONROY
LUIS ALONSO GÓMEZ GAMBOA
#sgnext

2. PRUEBA DE SOFTWARE Y AUTOMATIZACIÓN

3. CONCEPTOS BÁSICOS
• Prueba de Software
– Proceso paralelo al de desarrollo para determinar si el producto
alcanza el nivel de calidad acordado
• Caso de Prueba
– Información necesaria para aplicar una prueba muy específica
al sistema con el que se está trabajando
• Pruebas progresivas
– Primera aplicación de la prueba diseñada
• Pruebas regresivas
– Pruebas realizadas al sistema para verificar que no aparecen nuevos
defectos como consecuencia de una modificación al sistema

4. Automatización
• Herramientas para la prueba
• La prueba de software es una disciplina que implica la
realización de muchas actividades
• Lo que buscamos automatizar es lo que consume más tiempo y
es repetitivo
• La ejecución de la prueba consume un porcentaje muy alto de
las pruebas en un proyecto

5. Costos de la automatización
• La automatización tiene costos importantes asociados a la
preparación de la prueba
• La fase de ejecución es donde se obtiene el retorno de la
inversión
• La madurez del código es muy importante ya que cada que un
caso de prueba requiere mantenimiento se reduce su beneficio
• Entre más veces se ejecute un caso de prueba automatizado el
valor ganado crece

6. Costo-Beneficio de automatizar
• Automatización de casos de prueba
Diagramas de Kiviat
Caso de prueba manual Caso de prueba automatizado Caso de prueba automatizado
re-usado

7. Uso Efectivo de Herramientas
• Potenciales beneficios del uso de herramientas.
– Trabajo repetitivo se reduce.
– La consistencia y repetibilidad es mayor.
– Evaluación objetiva.
– Incremento de la cobertura en las regresiones
• Riesgos del uso de herramientas.
– Expectativas no realistas de la herramienta.
– Subestimar tiempo, costo y esfuerzo de su introducción.
– Subestimar tiempo, costo y esfuerzo para alcanzar uso óptimo.

8. Uso Efectivo de Herramientas
• Riesgos
– Subestimar el esfuerzo de mantener lo productos generados por y para la
herramienta.
– Sobrevalorar la herramienta.
– Mal control de versiones de los productos.
– Adquirir herramientas incompatibles.
– Perder soporte para la herramienta.
– Que la herramienta tenga mal soporte.
– Si la herramienta es open-source o gratuita que se suspenda esta condición.
– Problemas con actualizaciones (nuevas plataformas)

9. ENFOQUES PARA LA AUTOMATIZACIÓN

10. Principales enfoques.
• Capture and replay. Sólo para efectos didácticos.
• Sólo con scripts. Cada caso de prueba es un script.
• Data Driven Testing. Scripts genéricos, los datos de prueba en
archivos separados.
• Keyword Driven Testing. Scripts todavía más genéricos,
combinado con Data Driven su potencial es mucho mayor.

11. Script para cada Caso de Prueba
• Cada caso de prueba se convierte en un script, los datos de prueba
están inmersos en el script
• Ventajas.
– Se reduce el trabajo repetitivo
– La consistencia y repetibilidad es alta
– Se puede ejecutar la prueba mientras el tester hace otra cosa
• Desventajas
– Se requiere habilidades de programación para todo el equipo de prueba
– El mantenimiento suele ser muy caro, sobre todo si el sistema a probar es
inmaduro

12. ROI de la automatización
Caso de Estudio*:
Valor de la automatización de la prueba
*Linz, T., Daigl, M. GUI Testing Made Painless. Implementation and Results of the ESSI Project
Number 24306. 1998
Preparación Ejecución
N
Gasto después de n ejecuciones
Prueba Manual Automatizada Manual Automatizada 1 5 10 20
Test 1 16.00 56.00 24.00 1.00 1.74 143% 45% 26% 15%
Test 2 10.00 14.00 2.00 0.10 2.11 118% 73% 50% 32%
Test 3 10.00 16.00 4.50 0.20 1.40 112% 52% 33% 20%
Test 4 20.00 28.00 1.50 0.20 6.15 131% 105% 86% 64%
Test 5 10.00 15.00 1.00 0.10 5.56 137% 103% 80% 57%
Test 6 10.00 15.00 1.50 0.10 3.57 131% 89% 64% 43%
Test 7 10.00 11.50 0.75 0.10 2.31 108% 87% 71% 54%
Test 8 10.00 11.50 0.50 0.10 3.75 110% 96% 83% 68%
Test 9 10.00 14.00 3.00 0.10 1.38 108% 58% 38% 23%
Test 10 10.00 10.60 0.50 0.10 1.50 102% 89% 77% 63%
Total 116 191.6 39.25 2.1 2.03 125% 65% 42% 26%

13. Riesgo de la Automatización
0
5
10
15
20
25
Preparación Ejecución Mantenimiento
Manual
Automatizado
0
5
10
15
20
25
Manual Automatizada
Ejecución
Ejecución
Preparación
0
5
10
15
20
25
30
Manual Automatizada
Ejecución
Ejecución
Ejecución
Preparación
0
5
10
15
20
25
30
Manual Automatizada
Mantenimeinto
Ejecución
Ejecución
Preparación

14. Data Driven Testing
Los datos de entrada se mantienen en archivos separados, así,
los scripts de prueba toman los datos de entrada de éstos
archivos y los introducen al sistema a probar
Ventajas
• Reducen el mantenimiento y se vuelven evolutivos
• Proveen cierta estructura al código de automatización
• Mayor eficiencia. Testers definen los datos de prueba, expertos
en automatización programan los scripts

15. Data Driven Testing
• Desventajas
• Requiere habilidades más altas
– Habilidades para programar los scripts
– Habilidades para el manejo de datos
• Los archivos de datos pueden llegar a crecer demasiado con
ciertas aplicaciones

16. Que es Keyword Driven Testing?
• Los casos de prueba hechos en keyword driven consisten en un
conjunto de keywords (comandos) que definen la secuencia de
acciones que se deben simular en la aplicación (SUT).
• Cada keyword (o comando) corresponde a una acción
individual como un Click, Doble Click, Cerrar Ventana,
Seleccionar una opción de menú, etc.

17. Keyword Driven Testing
• Ventajas
– No requiere conocimientos avanzados de programación. Por tanto no
se requiere un ingeniero de automatización que implemente la
manipulación de los controles del GUI
– Se facilita el desarrollo de los casos de prueba debido a que las
instrucciones ocultan la complejidad de la implementación
– Los casos de prueba son fáciles de leer y comprender por todos los
miembros del equipo

18. Keyword Driven Testing
• Ventajas
– Fácil de aprender. (Se agiliza la capacitación del personal de QA)
– No requiere que el GUI este terminado, por tanto se pueden
automatizar las pruebas desde las fases tempranas del desarrollo

19. Keyword Driven Testing
• Desventajas
– Difícil de implementarlo uno mismo. (la implementación requiere
técnicas para interpretar un lenguaje entre muchas otras cosas)
– Es fácil hacerlo mal sin los conocimientos y experiencia necesario

20. Keyword Driven Testing
Command Target Parameter
START_BROWSER Chrome www.google.com
TYPE SearchTextBox Google
PRESS Enter
CLICK link=Google Maps
IF Page.Title*=Google Maps
LOG Message Test passed :)
ELSE
LOG Error Test failed :(
END_IF
SLEEP 2000
CLOSE_BROWSER
Ejemplo #1: Búsqueda en Google

21. Keyword Driven Testing
Command Target Parameter
START_BROWSER Firefox www.google.com
CLICK link=Gmail
CLICK link=Sign in
TYPE PasswordTextBox password
CLICK Button(Sign in)
EXPORT_TO_TEXT InboxTable C:actualcorreos.csv
COMPARE_FILES C:actualcorreos.csv C:esperadocorreos.csv
VERIFY_TEXT EmailCountLabel 1-50 of 152
CLICK_CELL InboxTable 0,3
EXPORT_TO_TEXT EmailContentPanel C:actualcorreo1.txt
COMPARE_FILES C:actualcorreo1.txt C:esperadocorreo1.txt
CLOSE_BROWSER
Ejemplo #2: Extraer y comparar datos de una página web

22. Keyword Driven Testing
Command Target Parameter
READ_CSV C:test_datamy_parameters.csv
STORE rows ${LAST_RESULT}
FOR_EACH row rows
IF row[Included] == “N”
CONTINUE
END_IF
GET_WINDOW MainWindow.Id
CLICK MainWindow.MenuBar File|Open Project|row[“Project Name”]
CALL MainWindow.WaitTillProgressBarFinish
END_FOR
Id, Included, Project Name
ProjData_001, N, 1KTasks
ProjData_002, Y, 1MTasks
ProjData_003, N, 3KTasks
my_parameters
Ejemplo #3: Leer de un archivo CSV

23. Camino recorrido hasta llegar a
Keyword Driven
- Debíamos probar un producto que implicó aproximadamente 500
meses hombre de desarrollo (300,000 líneas de código)
(equivalente a 40 desarrolladores durante 1 año)
- Iniciamos con un sistema de regresiones basado en scripts y
archivos MS Excel
- Con el tiempo, los scripts crecieron hasta llegar a ser más de
50,000 líneas de código.
- El mantenimiento a los scripts era muy difícil para alguien sin
experiencia
- Dicho sistema estuvo en uso por 5 años

24. Camino recorrido hasta llegar a
Keyword Driven
- Hubo una oportunidad y la aprovechamos para re-diseñar el
sistema de regresiones
- Después de mucho investigar nos encontramos con el enfoque
Keyword Driven
- Ahora el mantenimiento a los scripts es fácil y rápido
- Los ingenieros de pruebas trabajan con mas gusto y hacen
carrera en la empresa

25. Test Suite
Test Case Procedimientos
Test Steps
Sistema Keyword Driven
Ejemplo Real #1: Aplicación Desktop

26. Sistema Keyword Driven
Ejemplo Real #1: Log de resultados

27. Sistema Keyword Driven
Ejemplo Real #2: Aplicación Web

28. Keyword Driven: Conclusiones
• Se potencializa la eficiencia de los testers
• Se generan casos de prueba más robustos porque son menos
sensibles a los cambios en la aplicación
• La creación y mantenimiento de los casos de prueba es mas
rápida
• Los casos de prueba son fáciles de leer. Así, al mismo tiempo
quedan “documentados”
• La automatización puede iniciar antes de que el GUI esté
terminado

29. Conclusiones Finales
• Los testers tienen habilidades particulares
• Los buenos testers no siempre tienen buenas habilidades de
programación
• Un desarrollador con conocimientos de prueba es un buen
candidato a programar los scripts (asociados a los Keywords)
• Los testers pueden seguir haciendo lo que mejor saben
• Si buscamos mejorar el desempeño, preguntémonos: ¿Los
testers son las personas ideales para programar?

30. ¿PREGUNTAS?
AARÓN MORENO MONROY. www.linkedin.com/in/aaron-moreno-eQ
LUIS ALONSO GÓMEZ GAMBOA. www.linkedin.com/in/luisalonsogg