Algo a lo que hemos llegado varias veces en Abstracta, es que no se trata solo de usar las herramientas de automatización para automatizar test cases. En este post quiero hablar de automatización basada en heurísticas. Tenemos herramientas mucho más poderosas que simplemente reproducir siempre la misma serie de pasos, podemos automatizar casos que no serían ejecutables por una persona, por ejemplo:
- recorrer todos los registros de la base de datos y verificar que se muestren correctamente en pantalla,
- probar que la facturación funcione correctamente tanto cuando hay un solo producto ingresado como cuando hay 100 items diferentes,
- validar links o cualquier recurso secundario, incluso, descubríendolos automáticamente (algo del estilo de la exploración que hace Monkop en mobile),
- y así como eso, lo que se les ocurra.
Esto especialmente considerando tareas que serían sumamente tediosas para una persona, y que un script con un algoritmo podrían fácilmente resolver. También están todos los aspectos técnicos que un tester no podría validar fácilmente y que utilizando el poder de un lenguaje de programación se puede facilitar este tipo de tareas (revisar propiedades de archivos, atributos o parámetros a nivel de protocolo, etc.).
Está interesante lo que encontré en este artículo de StickyMinds: Heresy! Automation Does Not Require Test Cases:
Traditionally, automated scripts are derived from existing test cases. But if we divorce the notion of “automation” from the notions of “test cases” and “test scripts,” we can think of automation as a judicious use of technology to help humans do their jobs. This broadens our world to include different tools that can help testers increase coverage, test faster, and detect trends.
Otro aspecto en esta línea es la automatización basada en heurísticas que mencionaba antes. Esto es más que nada necesario cuando no contamos con oráculos fijos. Esto es algo que me quedó muy marcado de un artículo de Harry Robinson. El ejemplo que daba para explicar esto refiere a cuando él trabajaba en Google. Imaginen cómo probar el cálculo del camino más corto en Google Maps.
Lo que él planteaba era hacer un script que busque los caminos de A a B (tomando A y B totalmente aleatorios) y luego que calcule de B a A. Si la diferencia entre ambas distancias es mayor a un 10% entonces tenemos se levanta un warning, alguien tiene que mirarlo. Acá está bien explicado este enfoque. No significa que necesariamente haya un error, pero tal vez haya algo para revisar. Entonces, ahí no hay un caso de prueba fijo, sino que la automatización fue utilizada para algo mucho más amplio, y hasta podríamos decir que exploratorio.
Una vez David Giordano (de Abstracta) me dijo lo siguiente: Automatizar mediante un script y crear un “autómata” son cosas complementarias y son para objetivos diferentes.
