DEV Community: enriquedcs

Automatizacion de Pruebas Visuales - requerida o solo herramientas de moda?

enriquedcs — Sun, 22 Aug 2021 18:14:51 +0000

Que es la automatizacion de pruebas visuales?

Algunas veces referido como pruebas de inerfaz visual de usuario o pruebas de regresion visuales, las VTA (Visual Test Automation) validan las aplicaciones desde una perspectiva visual (Tomando pantallazos y comparandolo con alguno previamente aprobado). Estas apruebas ayudan a resolver los retos relacionado a cambios visuales en las aplicaciones y proveen una certeza aprobado en cuanto a la interfaz de usuario.

VTA es acerca de que partes del UI son mas importantes de probar (Pruebas de cobertura visual).

Quizas, puede relacionarse a las pruebas funcionales, basado en ese punto se puede automatizar hasta cierto punto, pero a diferencia de la pruebas funcionales en las que se puede corroborar un resultado esperado, los resultados de las pruebas visuales van mas alla que un simple pass/fail.

Sin subestimar las VTA

Antes de hablar de como se evoluciono de simples pruebas funcionales acerca de las pantallas a VTA, necesitamos entender el estado actual de las pruebas visuales. Las scripts de pruebas funcionales pueden validar tamaño, posicion y el esquema de color de los elementos visuales.

Como QA's realizamos algunas pruebas ad hoc o de exploracion, para encontrar algunos casos fuera de lo normal, y defectos visuales, pero, puede ser muchas veces algo dificil de verificar considerando las multiples pantallas y las multiples combinaciones.

Algunos años atras existia un proceso de validar las imagenes usando pixeles. Este proceso esta relacionado a los bitmaps o las pantallas que eran capturadas en ciertos puntos y despues se validaba y comparaba via pixeles con una base de bitmaps. Las herramientas de comparacion de pixeles pueden encontrar diferencias rapidamente relacionadas a diferencias de pixeles.

Si estas herramientas ya existian porque no se popularizo su uso para encontrar problemas visuales? En si varias cosas no se tomaban en cuenta al momento de validar los pantallazos por ejemplo:

Variacion en las resoluciones
Hardware mostrando bitmaps de manera diferente
Variacion en los fuentes o elementos de los navegadores
Contenido dinamico

Ahora enfoquemonos en VTA, actualmente las herramientas usan vision computarizada como la parte esencial para la comparacion visual y las diferencias visuales, a diferencia de las herramientas de comparacion de pixeles, las herramientas de VTA no necesitan ambientes especiales para ser eficaces.

Combinando las pruebas de automatizacion y el procesamiento de imagenes, las pruebas visuales pueden ayudarnos a que las aplicaciones se muestren como deberia, lo cual seria un gran reto de alcanzar solo con las pruebas funcionales y los chequeos de las pruebas automatizadas.

En este punto VTA suena como algo que pudieramos usar y de gran ventaja para nuestros proyectos o nuestros POC's. Quizas te estes preguntando es esto realmente nuevo? Tenemos varias herramientas para automatizar las pruebas de regresion visual.

Actualmente vemos varias compañias adoptando VTA usando diferente herramientas actualmente disponibles como son applitools eyes, o la reciente adquisicion de Percy por browserstack, screener, chromatic, entre otras.

La fuerza esta en Visual Test Automation

La adopcion de herramientas para pruebas visuales puede ser de gran ayuda, en este punto como Testers diriamos wow, suena genial cuando empezar a usar VTA en mi framework? Para este caso mi recomendacion es empezar con algunas herramientas open-source (Free VTA).

Lo unico cierto en la vida es muerte, impuestos y defectos en el codigo.

References

Percy Tool

Applitools

Graphical Interface

Visual Test Automation

Github Applitools

Patron de pruebas automatizadas Screenplay

enriquedcs — Fri, 18 Jun 2021 18:36:09 +0000

Antes de hablar del patron Screenplay, me gustaría definir que es un patron de pruebas automatizadas, para aquellos que no se encuentren familiarizados con el concepto, "Un patron de pruebas automatizadas es una manera de resolver algún problema en las pruebas automatizadas y que ha podido resolver con una serie de practicas estandarizadas para muchas personas".

Algo ha tomar en cuenta, un patron no es una serie de pasos como una receta de cocina. En otras palabras un patron se puede adaptar e implementar en nuestro contexto, ayudándonos a resolver algunos de los problemas que pudiéramos tener en especifico.

Exploremos un poco el panorama de las pruebas automatizadas, si actualmente nos encontramos trabajando en proyecto de pruebas automatizadas y estamos construyendo nuestro framework desde cero, la opción mas obvio por muchos es POM (Page Object Model), pero quizá POM no sea la opción mas optima para nuestro actual proyecto.

Recordemos que podemos usar una variedad de patrones al momento de implementa nuestro framework de pruebas automatizadas, mi sugerencia es identificar el que mas haga sentido para nuestro proyecto.

Familiarizándonos con el patron Screenplay

Screenplay trata acerca de escribir nuestras pruebas automatizadas basado en los principios de ingeniería de software tal como son el principio de responsabilidad individual (SRP) y en el principio de abrir y cerrar (Open-Closed).

Screenplay promueve los bueno hábitos de testing y suites de pruebas bien organizadas las cuales son facil de seguir, facil de mantener y facil de extender; habilitando equipos a escribir mas robustos y entendibles pruebas automatizadas. Todo buen patron debe tener buenos hábitos de pruebas, pero en realidad, debemos poner atención en la implementación correcta.

El patron de screenplay ha estado desde el 2007, algunos de los precursores son Antonio Marcano, Andy Palmer, Jan Molak y Jason Ferguson. Existen excelentes explicaciones acerca de los conceptos del patron y los problemas comunes que trata de resolver. Para aquellos familiarizados con el patron de Page Object sabemos que puede ser un poco alto el costo de mantenimiento cuando la solución de automatización crece.

En el patron de screenplay, las pruebas describen como un usuario puede interactuar con la aplicación para alcanzar una meta.

Un usuario interactuando con el sistema es llamado "Actor". Los Actores son la parte central del patron screenplay. Como Screenplay (Guion) los actores tienes uno o mas "Habilidades", como son la habilidad de navegar por la web o realizar una consulta un web service, el "Actor" tambien puede realizar "Tareas", como pueden ser agregar o remover objetos o cosas.

Para interactuar con la aplicaciones, como pueden ser introducir valores en los campos o dar click en botones, los actores necesitan estas interacciones, las cuales son denominadas "Acciones". Los "Actores" pueden hacer "Preguntas" acerca del estado del sistema, como por ejemplo leer un valor de un campo en la pantalla o realizando una consulta a algun web service, de tal forma es como se prueba usando el patron de screenplay.

Implementación del patron Screenplay

Para este ejemplo del patron de Screenplay usaremos Python, para ser específicos un modulo llamada ScreenPy, ScreenPy es una libreria que provee la base para nuestra suite de preubas automatizadas.

pip install screenpy

Para hacer la configuración del patron Screenplay usando ScreenPy, necesitamos ejecutar el siguiente comando dentro de la carpeta de nuestra suite de pruebas:

python -m screenpy-quickstart.py

Este comando creara la jerarquia de archivos por nosotros:



\test_suite_folder
  \features #this is where the actual test files will live
    + feature1.py
    + ...


    \user_interface # files containing locators and/or URLs for each page
    +page1.py
    + ...

Podemos tener otras carpetas por ejemplo "Acciones", "Tareas" o "Habilidades" dependiendo de las capacidades de nuestros "Actores".

Como mencionamos arriba, el patron de Screenplay se centra enteramente en los que nuestros usuarios finales quieren hacer en su sitio, en este caso, nuestros casos de prueba se centraran en lo que nuestros "Actores" pueden hace, como puede ser ganar "Habilidades", realizar "Acciones" y realizar "Preguntas".



from screenpy.actor import Actor, AnActor
from selenium.webdriver import Firefox
from screenpy.abilities import BrowseTheWeb


Anton = AnActor.named("Anton").who_can(BrowseTheWeb.using(Firefox()))

Como podrán observar Anton, nuestro actor esta listo para darnos una actuación de antología con su nueva habilidad "BrowseTheWeb". Ahora necesitamos realizar algunas acciones con su nueva y unica habilidad.



from screenpy import Target
from screenpy.actions import Click

#the string to use as a locator for the element can be a CSS selector or an xpath string
GOOGLE_LINK = Target.the("http://www.google.com").located_by("css select")
Anton.attempts_to(Click.the(GOOGLE_LINK))

Anton esta listo para actuar (En este caso una prueba), recordemos que las pruebas se realizan con "Preguntas":



from screenpy.questions import Text
from screenpy.resolutions import ReadsExactly

GOOGLE_MESSAGE = Target.the("google_message").located_by("div:nth-of-type(1) > .rc .st")
Anton.should_see_the((Text.of(GOOGLE_MESSAGE), ReadsExactly("Test"))

A continuation un ejemplo con estructura de pruebas:

/feature/test_iframe.py



import unittest


from screenpy import AnActor, given, then, when
from screenpy.abilities import BrowseTheWeb
from screenpy.actions import Open, SwitchTo
from screenpy.pacing import act, scene
from screenpy.questions import Text
from screenpy.resolutions import ReadsExactly
from tasks import start


from user_interface.iframe import CONTENT, URLI, IFRAME

class TestFrames(unittest.TestCase):


    def setUp(self):

        self.actor = AnActor.named("Anton").who_can (BrowseTheWeb.using_firefox())

    @act("Perform")
    @scene("SwitchTo")
    def test_switch_to_iframe(self):

      Anton = self.actor

      given(Anton).attempts_to(Open.their_browser_on(URL))
      when(Anton).attempts_to(SwitchTo.the(IFRAME))
      then(Anton).should_see_the(
          (Text.of_the(CONTENT_BOX), ReadsExactly("Your content goes here."))
      )

    def tearDown(self):
        self.actor.exit()

/user_interface/iframe.py



# Locators and URL for the Iframe page.

from screenpy import Target

URLI = "http://the-internet.herokuapp.com/iframe"

IFRAME = Target.the("Iframe").located_by("#mce_0_ifr")
CONTENT = Target.the("The content box").located_by("p")

La filosofia de Python, es baterias incluidas, despues de instalar Screenpy las siguientes dependencias seran instaladas tambien: Selenium, Allure's pytest plugin, pytest, and PyOTP.

Si queremos ver algun reporte en Allure, necesitaremos agregar "--alluredir allure_report", y despues generar los reportes de Allure, "allure serve allure_report" y listo, no necesitamos otra configuración extra (Solo como detalle Allure debe estar disponible localmente https://tinyurl.com/y2rv2ebp).

Si necesitan mas información pueden encontrar ejemplos en el siguiente repo.

Conclusion

El patron de Screnplay es una excelente alternativa y pueden mejorar nuestras soluciones de pruebas automatizadas. Cada proyecto es diferente y a veces necesitamos crear soluciones que puedan ser sostenibles. Les recomiendo este patron si se acopla a sus necesidades especificas. Este patron de Screenplay puede sustituir al modelo Page Object o incluso como complemento.

Entiendo que al principio puede ser un gran reto la implementación, pero, una vez que que vemos los beneficios en cuanto reusabilidad y escalabilidad, puede llegar a ser de gran ayuda a nuestra base de conocimientos. Por ultimo si estan usando el patron de Screenplay con Javascript (Aparte de Serenity), compartan que modulo o componente es el de su elección.

Por ultimo los principios de SOLID pueden ayudar a evitar que su solución de pruebas automatizadas tenga fallas.

Felices Pruebas!

References

Selenium Design Patterns and Best Practices, Dima Kovalenko

https://www.infoq.com/articles/Beyond-Page-Objects-Test-Automation-Serenity-Screenplay/

https://screenpy-docs.readthedocs.io/

https://moduscreate.com/blog/the-screenplay-test-design-pattern/

TestProject una herramienta gratis para Pruebas Automatizadas.

enriquedcs — Mon, 24 May 2021 21:30:24 +0000

Para los entusiastas de las Pruebas automatizadas (Test Automation), Testproject es una gran herramienta completamente gratis que nos facilita la integración de lenguajes como C#, Java, Python y actualmente Javascript usando sus SDKs. Y para los que quieren iniciar en el mundo de las Pruebas automatizadas, TestProject incluye un recorder que nos facilita mucho la obtención de elemento y nos va llevando paso a paso tanto para pruebas web como para móviles.

El dia de hoy me gustaría comentarles de cómo podemos tomar ventaja del SDK usando el lenguaje Python; antes que nada hay que seguir los siguientes pasos:

Si aún no tienes tu cuenta de TestProject, la puedes crear haciendo clic en el siguiente enlace, recuerda que es gratis > Testproject

Una vez que tu cuenta ha sido creada, es tiempo de descargar el agente para poder correr nuestras pruebas, hay que descargar el que se adapta a nuestro sistema operativo. (Algo a destacar si también se puede usar TestProject con docker, ese tema será para un artículo más adelante).

Necesitamos correr el agente localmente y especificar un alias.

Recuerda nombrar a tu agente con algo que sea facil y rapido de identificar.

Algo muy importante es adquirir nuestra llave de desarrollador (Llave de desarrollador, pero mi trabajo es hacer pruebas, en si es solo un token el cual nos ayudara a identificar nuestro agente y para sincronizar nuestro SDK) debes de hacer clic en el enlace link.

Ya que hemos instalado nuestro agente de TestProject es momento de instalar el SDK de python el cual se encuentra disponible en el administrador de Paquetes en Python, en este caso PIP.



pip install testproject-python-sdk

Una vez que la instalación ha finalizado estamos listos para hacer algunas Pruebas Automatizadas.

Usando el SDK de Python y TestProject

Al momento de escribir esta reseña, el SDK Python soporta lo siguientes navegadores:

Chrome (incluido headless)
Firefox (incluido headless)
Internet Explorer
Edge
Safari
Android (usando appium)
IOS (usando appium)

La implementación es sumamente sencilla si conoces algo de lenguaje Python, notaras que es super facil despues de instalar el agente de TestProject, enseguida podrás encontrar un ejemplo:



import os
from dotenv import load_dotenv
from selenium.webdriver import ChromeOptions
from src.testproject.sdk.drivers import webdriver
from src.testproject.decorator import report


@report(project='My python Project', job='First job')
def testproject_test():


  chrome_options = ChromeOptions()
  chrome_options.headless = True                    

driver = webdriver.Chrome(chrome_options=chrome_options, token=os.getenv('DEV_TOKEN'))

  <your code>

  driver.quit()

testproject_test()

A su vez puedes encontrar una implementación de Webdriver sumamente fácil.



if self.browser == "Iexplorer":
    driver = webdriver.Ie()
  elif self.browser == "Firefox":
      driver = webdriver.Firefox()
  elif self.browser == "Edge":
      driver = webdriver.Edge()
  elif self.browser == "Safari":
      driver = webdriver.Safari()
  elif self.browser == "Headless"
      chrome_options = ChromeOptions()
      chrome_options.headless = True
      driver = webdriver.Chrome(chrome_options=chrome_options) 
  else:
        driver = webdriver.Chrome()

Algo que hay que destacar al usar TestProject, son los reportes que genera, sin necesidad de instalar addons o plugins aparte TestProject nos entrega unos reportes detalladas de ejecución en formato PDF o HTML y la verdad son super útiles al momento de presentar algún estatus de la ejecución de Pruebas.

Para aquellos familiarizados con los reportes que genera Allure o HMTLTestRunner (Pueden encontrar más detalles aquí), TestProject genera prácticamente esos reportes como mencionaba anteriormente sin la necesidad de alguna instalación aparte y podemos agregar cosas a esos reportes de manera fácil y rápida.



from src.testproject.decorator import report

result = driver.find_element_by_css_selector("#dropdown").is_displayed()

driver.report().step(description='Test Status', message='Reporting from Python SDK', passed=result, screenshot=True)

Algo a destacar es la facilidad de usar Pytest en conjunto con los reportes de TestProject, aquí puedes encontrar un ejemplo de ello.

Para aquellos que piensen que es algo tardado, les comento que realice el setup de TestProject y SDK en una nueva máquina virtual y me tomó menos de 5 minutos la instalación y configuración del SDK en Python. Las validaciones se hicieron en los siguientes navegadores: Chrome, Chrome Headless, Firefox, Firefox Headless, Edge* y Safari. Todos se ejecutaron correctamente y sin ningún esfuerzo extra incluido el reporteador de TestProject.

Algo importante a destacar es el soporte de TestProject, muchos que usamos herramientas de código libre, comprendemos que el soporte es casi nulo y muchas veces nos apoyamos en la comunidad, para el caso de Testproject, el soporte es muy bueno en caso de que encuentres con algún problema, la respuesta es muy rápida y orientada a la solución.

Conclusión

TestProject es una gran herramienta que nos puede ayudar a ejecutar pruebas de Selenium y Appium como una plataforma unificadora de la cual se podemos tomar ventaja en la parte de configuración y mantenimiento usando los SDKs. Es muy versátil ya que podemos integrar scripts usando Java, C#, Python y Javascript.

Si actualmente estás usando Python o Javascript en tus pruebas, mi recomendación es que intentes TestProject, aparte de tener una configuración e instalación mas fácil y rápida sus reportes incluidos pueden ser de gran ayuda en nuestras Pruebas automatizadas. Si aún no tienes tu cuenta gratis de TestProject, me parece el momento de crear una, el proceso de creación no toma más de un minuto y los beneficios son muy altos.

¡Felices Pruebas!