Implementación de pruebas continuas con BrowserStack: conceptos clave

Este articulo provee la información esencial para la comprensión y manejo de BrowserStack como proveedor de servicio de granjas de pruebas en la nube. Incluye información descriptiva y conceptual, con instrucciones y ejemplos para facilitar su implementación.

El enlace principal donde puedes encontrar toda la documentación oficial y la información detallada relacionada con BrowserStack, incluyendo productos, guías de integración, APIs y casos de uso, es: **Documentación para Desarrolladores de BrowserStack**

• Productos populares: Live (pruebas manuales), Automate (automatización web), App Live (pruebas manuales en apps móviles), App Automate (automatización móvil) y Percy (pruebas visuales).
• Temas principales: Pruebas locales (Local Testing), integración CI/CD (Jenkins, Azure, etc.) y configuración de capabilities.
• Guías de integración: Detalles para trabajar con frameworks como Selenium, Cypress, Playwright, y Appium.

¿Qué son las pruebas continuas (Continuous Testing)?

Las pruebas continuas son un tipo de pruebas de software que se integran en cada etapa del ciclo de vida del desarrollo dentro de un marco DevOps. El objetivo principal es evaluar la calidad del software de manera temprana y frecuente como parte del proceso de entrega continua (Continuous Delivery).

A diferencia de las pruebas tradicionales, donde el desarrollo y la garantía de calidad (QA) son fases aisladas y secuenciales que priorizan la calidad sobre el cronograma, las pruebas continuas integran la calidad desde el inicio.

Ventajas de las pruebas continuas

• Aceleración en la entrega: La detección temprana de errores (estrategia de “cambio a la izquierda”) ahorra tiempo, dinero y recursos.
• Calidad de código mejorada: Reduce los errores manuales y mitiga el potencial de defectos.
• Integración fluida: Se acopla perfectamente en el proceso DevOps.
• Mayor velocidad de comercialización (Time-to-Market): Gracias a un circuito de retroalimentación continuo.
• Mejora de la eficiencia: Fusiona equipos aislados (desarrollo, pruebas y operaciones).
• Seguridad reforzada: Establece un sistema de soporte que protege las aplicaciones contra cambios o ataques inesperados, asegurando la estabilidad y recuperabilidad.
• Enfoque en la experiencia del usuario: Se adapta a los requisitos cambiantes del cliente mediante actualizaciones constantes basadas en *feedback, permitiendo la creación de casos de prueba efectivos para el frontend* y el backend.
• Consistencia: La automatización de pruebas mejora la consistencia en la configuración de todas las pruebas relevantes.
• Mitigación de riesgos: El desarrollo ágil se centra en las expectativas comerciales.
• Acceso general: Provee acceso al entorno de prueba con virtualización de servicios.

Desventajas de las pruebas continuas

Alto costo: Puede ser menos rentable para equipos de desarrollo más pequeños.

Integración de pruebas continuas con el proceso de desarrollo

El proceso de pruebas continuas puede incluir diferentes opciones, como:

1. Pruebas estática. En el siguiente enlace se encuentra un documento que describe en detalle los conceptos, técnicas y objetivos de las pruebas estáticas: **Pruebas Estáticas | PDF | Software | Informática — Scribd**

2. Pruebas paralelas con granjas. Integrar su suite de pruebas Java con Automate (BrowserStack): https://www.browserstack.com/docs/automate/selenium/getting-started/java/integrate-your-tests

Pruebas paralelas con granjas en Continuous Testing (Ejemplo con Gradle)

A continuación, se detalla un proceso de configuración utilizando Gradle para la ejecución de pruebas paralelas.

Paso 1. Configuración del proyecto: Tener un proyecto con Gradle o Maven en un IDE.

Paso 2. Configuración en build.gradle (Gradle): Configura el archivo build.gradle para la ejecución de pruebas, considerando si se necesita una ejecución única (‘single’) o paralela (‘parallel’).

Paso 3. Inserción de dependencia local (Opcional): Si el sistema de prueba requiere una ejecución local, inserta la siguiente dependencia:

gradle

implementation group: ‘com.browserstack’, name: ‘browserstack-local-java’, version: ‘1.0.6’ o superiror

Paso 4. Configuración de capabilities: Si se utiliza Serenity BDD, se recomienda usar el archivo ‘serenity.properties’ para delegar la creación de drivers y la asignación de capabilities.

Paso 4.1. Uso de ‘serenity.properties’: Si utilizas ‘serenity.properties’, puedes agregar las siguientes variables, las cuales serán usadas para crear las instancias de los drivers antes de la ejecución de las pruebas:

properties

**CONFIGURACIONES NECESARIAS PARA CREACIÓN DE DRIVER/**

webdriver.driver = provided

webdriver.provided.type = driver

webdriver.provided.driver = Ruta donde se encuentra la clase driver

serenity.driver.capabilities = driver

/CONFIGURACIONES NECESARIAS PARA CONECTAR/

browserstack.user=BROWSERSTACK_USERNAME

browserstack.key=BROWSERSTACK_ACCESS_KEY

browserstack.build=BROWSERSTACK_ACCESS_KEY

browserstack.server=hub-cloud.browserstack.com

/CONFIGURACIONES GENERALES/

bstack_browserstack.debug=true

bstack_browserstack.console=info

bstack_browserstack.local=false

bstack_browserstack.video=true

bstack_browserstack.networkLogs=true

/CONFIGURACIONES EN CASO DE PRUEBAS UNICAS/

environment.single.name=single_test

environment.single.browser=IE

environment.single.browser_version=11

environment.single.os=Windows

environment.single.os_version=10

environment.single.project=Automation BrowserStack

/CONFIGURACIONES EN CASO DE PRUEBAS PARALELAS/

El parallel_1 y parallel_2 va aumentando

Según número de test paralelos que quiera

Crear, por ejemplo si tiene 5, crearía hasta el

Parallel_5 y cada uno con sus configuraciones de

Entorno.

environment.parallel_1.name=parallel_test

environment.parallel_1.browser=firefox

environment.parallel_2.name=parallel_test

environment.parallel_2.browser=safari

environment.parallel_3.name=parallel_test

environment.parallel_3.browser=Chrome

environment.parallel_3.os_version=7

environment.parallel_3.os=Windows

/CONFIGURACIONES NECESARIAS PARA CREACIÓN DE DRIVER/

webdriver.driver = provided

webdriver.provided.type = driver

webdriver.provided.driver = Ruta donde se encuentra la clase driver

serenity.driver.capabilities = driver

/CONFIGURACIONES NECESARIAS PARA CONECTAR/

browserstack.user=BROWSERSTACK_USERNAME

browserstack.key=BROWSERSTACK_ACCESS_KEY

browserstack.build=BROWSERSTACK_ACCESS_KEY

browserstack.server=hub-cloud.browserstack.com

/CONFIGURACIONES GENERALES/

bstack_browserstack.debug=true

bstack_browserstack.console=info

bstack_browserstack.local=false

bstack_browserstack.video=true

bstack_browserstack.networkLogs=true

/CONFIGURACIONES EN CASO DE PRUEBAS UNICAS/

environment.single.name=single_test

environment.single.browser=IE

environment.single.browser_version=11

environment.single.os=Windows

environment.single.os_version=10

environment.single.project=Automation BrowserStack

/CONFIGURACIONES EN CASO DE PRUEBAS PARALELAS/

El parallel_1 y parallel_2 va aumentando

Según número de test paralelos que quiera

Crear, por ejemplo si tiene 5, crearía hasta el

Parallel_5 y cada uno con sus configuraciones de

Entorno.

environment.parallel_1.name=parallel_test

environment.parallel_1.browser=firefox

environment.parallel_2.name=parallel_test

environment.parallel_2.browser=safari

environment.parallel_3.name=parallel_test

environment.parallel_3.browser=Chrome

environment.parallel_3.os_version=7

environment.parallel_3.os=Windows

Paso 4.2: Creación de Driver sin **serenity.properties**

Si no usa el archivo de propiedades para asignar capabilities, debe crear un procedimiento

Paso 4.3. Creación de Driver Manual con Serenity: Alternativamente, si usas ‘serenity.propertie’, pero deseas gestionar la creación del driver tú mismo, elimina las primeras cuatro líneas de configuración de ‘webdriver.driver’ del ‘serenity.properties’ y usa:

Paso 5. Uso del driver: Una vez configurado, puedes usar el driver en tus pruebas heredando de la clase ‘getDriver()’ del core o continuar con el uso normal de tus pages si trabajas con Page Object Model (POM).

Recuerda: Lo único que cambia es el tipo de instancia del driver. El mapeo y el uso posterior permanecen iguales.

Paso 6. Ejecución y visualización: Ejecuta el test en las granjas, ya sea en consola o por comando. Dirígete al dashboard de BrowserStack y visualiza la ejecución.

Paso 7. Visualización de resultados: Al finalizar, el dashboard de BrowserStack, se mostrará el paso a paso ejecutado, las capabilities, el video (si se habilitó) y el resultado del test.

Paso 8. Personalización de resultados: Puedes personalizar la presentación del resultado de las pruebas con un procedimiento ‘@After para indicar el estado de la sesión en BrowserStack:

Integración de BrowserStack con CI/CD

BrowserStack se puede integrar con varios proveedores de Integración Continua (CI).

Integración con Azure DevOps

Para configurar la etapa de ejecución de automatizaciones en Azure DevOps:

• Opción por YAML:

Opción por interfaz: Consulta la documentación de Azure para la configuración a través de la interfaz gráfica.

Integración con Jenkins

Este es el enlace al repositorio del plugin, donde se detallan las características, los requisitos y la funcionalidad para gestionar las credenciales y los informes de las pruebas automatizadas.

• BrowserStack Plugin — Jenkins: https://wiki.jenkins-ci.org/JENKINS/BrowserStack-Plugin.html

Ejemplo:

Resultados

Integración con AWS

Consulta el link AWS — BrowserStack para la configuración.

Integrar tu suite de pruebas Selenium con AWS CodePipeline (BrowserStack Docs): https://www.browserstack.com/docs/automate/selenium/aws-codepipeline

La integración requiere que configures las variables de entorno (BROWSERSTACK_USERNAME y BROWSERSTACK_ACCESS_KEY) en tu proyecto de AWS CodeBuild y que ejecutes los comandos de tu suite de pruebas (como mvn test o npm run test) dentro del archivo buildspec.yml.

Ejemplo:

Errores frecuentes

• Variables de entorno: Si las variables de entorno no son reconocidas después de cargarlas, cierra y vuelve a abrir tu IDE.
• Credenciales: Revisa constantemente tus credenciales de usuario.
• Propiedad de Build en CI: En integraciones con CI, verifica que la propiedad ‘Build’ se conecte correctamente al proveedor. Si se conecta solo por medio del ‘serenity.properties’, es posible que no se extraigan los resultados.
• Capabilities: Verifica que las capabilities utilizadas sean válidas para los navegadores o entornos móviles que necesitas.