Sesión 1 de mi lab de QA Automation: Selenium + Java desde cero

Contexto: por qué reiniciar

Tenía código de automation armado. Funcionaba, pero no tenía control total sobre la arquitectura. Era código heredado, ajustado, parcheado.

Decidí reiniciar.

No porque lo anterior fuera malo, sino porque quiero construir algo desde cero, con criterio propio, documentando cada decisión.

Este repo (qa-automation-lab) es mi laboratorio público. Frameworks, decisiones técnicas, aprendizaje documentado.

Repo: github.com/cesarbeassuarez/qa-automation-lab

Control de versiones

Uso Git para versionar el código, con SourceTree como interfaz visual
(la misma herramienta que uso en el trabajo).

El repo: por qué un solo repo con subproyectos

La estructura es simple:

qa-automation-lab/
├── .git
└── selenium-java/

Por qué así:

• Un solo repo para todo el lab (Selenium, Cypress, Playwright en el futuro)
• Cada framework en su propio subproyecto
• Fácil de clonar, fácil de navegar
• Git gestiona todo desde la raíz

No quiero 10 repos dispersos. Quiero un solo lugar donde esté todo mi arsenal.

Decisiones técnicas del día 1

Por qué empiezo con Selenium (y no Cypress o Playwright)

Voy a aprender los 3 eventualmente. Pero arranco con Selenium.

Razones:

1. Demanda del mercado
Selenium + Java es el stack más pedido en QA Automation.

Busqué ofertas en Argentina + remoto (diciembre 2025):

• Selenium: ~70% de las ofertas
• Cypress: ~20%
• Playwright: ~10% (creciendo)

2. Multi-lenguaje
Selenium soporta Java, Python, C#, JavaScript, Ruby.
Si aprendés Selenium, podés moverte entre lenguajes.

Cypress: solo JavaScript
Playwright: multi-lenguaje, pero menos maduro

3. Madurez y ecosistema

• Selenium existe desde 2004, es el estándar histórico
• Documentación masiva
• Frameworks construidos encima (TestNG, JUnit, Cucumber)
• Cualquier problema que tengas, alguien ya lo resolvió

4. Testing cross-browser real
Selenium testea en Chrome, Firefox, Edge, Safari reales.
Cypress tiene limitaciones cross-browser.

Por qué NO Cypress primero:

• Solo JavaScript
• Limitaciones arquitecturales (no puede testear múltiples tabs/domains bien)
• Menos demanda laboral para roles Java

Por qué NO Playwright primero:

• Más nuevo, menos adopción en empresas grandes
• Menos ofertas de trabajo (aunque está creciendo)

Mi estrategia:

1. Dominar Selenium + Java → employable YA
2. Aprender Cypress después → versatilidad
3. Aprender Playwright al final → diferenciación

Por qué Java

Demanda del mercado:
Selenium + Java es el combo más pedido en Argentina y remoto.

De ~100 ofertas de QA Automation que revisé:

• Java: 60-70%
• JavaScript: 20-25%
• Python: 10-15%
• C#: 5-10%

Por qué Java sobre otras opciones:

JavaScript:

• Crece rápido con Cypress/Playwright
• Pero para Selenium, Java sigue siendo el líder
• Si arranco con Java, después pasar a JS es fácil

Python:

• Genial para scripting, APIs, data analysis
• En Selenium automation: menos demanda que Java
• Lo voy a aprender para Playwright

C#:

• Específico de ecosistema Microsoft/.NET
• Menos ofertas fuera de empresas Microsoft-heavy

Ventajas técnicas de Java:

• Tipado estático (menos errores en runtime)
• Ecosistema maduro (Maven, TestNG, Allure)
• OOP estructurado (bueno para frameworks grandes)
• IntelliJ está diseñado para Java

La realidad:
Java para QA Automation no es "el mejor lenguaje objetivamente".
Es el más demandado para conseguir trabajo.

Java 17

Por qué uso Java 17:

• LTS (Long Term Support)
• Versión estable, madura, soportada
• No necesito las features de 21 todavía
• No tiene sentido usar 11 (más vieja)

openjdk version "17.0.14" 2025-01-21
OpenJDK Runtime Environment Temurin-17.0.14+7

Por qué no 21: podría, pero 17 es suficiente para lo que voy a construir ahora. Si en el futuro necesito algo de 21, migro.

Por qué Maven

Por qué Maven y no Gradle:

• Más simple para arrancar
• XML claro (aunque verboso)
• Convenciones estándar
• Menos curva de aprendizaje

Gradle es más flexible, más moderno, pero Maven cumple lo que necesito sin agregar complejidad innecesaria.

Por qué IntelliJ IDEA

IntelliJ es el IDE estándar para Java automation en la industria.

Por qué IntelliJ sobre otras opciones:

VS Code:

• Sirve, pero requiere configurar manualmente Maven, JDK, debugging
• Está pensado para ser multi-lenguaje (bueno para JS, no óptimo para Java)
• Para Java, perdés tiempo en setup que IntelliJ resuelve out-of-the-box

Eclipse:

• Fue el estándar hace 10 años
• Más pesado, menos intuitivo
• Refactoring inferior al de IntelliJ
• Todavía se usa en empresas legacy

NetBeans:

• Casi no se menciona en ofertas de trabajo modernas

Demanda del mercado:
Busqué "QA Automation Java" en LinkedIn/Glassdoor Argentina + remoto.
El 70-80% de las empresas que contratan Java automation usan IntelliJ.

Ventajas concretas:

• Maven integration nativa (reload automático)
• Debugging visual potente
• Refactoring inteligente (renombrar variables, extraer métodos)
• Inspecciones de código en tiempo real
• Git integrado sin configuración

Desventaja que acepto:

• Más pesado que VS Code
• Versión completa es paga (pero Community es suficiente)

Para QA Automation con Java: IntelliJ es la mejor inversión de tiempo.

Estructura limpia desde el inicio

Al crear el proyecto en IntelliJ configuré:

• Name: selenium-java
• Location: D:\Proyectos\Testing\qa-automation-lab\selenium-java
• Build system: Maven
• JDK: temurin-17
• GroupId: com.cesar.qa
• ArtifactId: selenium-java

Sin código de ejemplo, sin basura preconfigurada.
Solo la estructura Maven base.

Estado actual: pom.xml creado, sin tests

Este es el pom.xml que IntelliJ generó:

Limpio. Sin dependencias todavía.
Sin plugins. Sin configuraciones extra.

Estructura actual:

selenium-java/
├── src/
│   ├── main/
│   │   └── java/
│   └── test/
│       └── java/
├── .gitignore
└── pom.xml

Carpetas vacías, listas para llenarse.

Primeras dependencias (Selenium, WebDriverManager, TestNG)

Instalé estas 3:

• Selenium → el core
• WebDriverManager → maneja drivers automáticamente (no más descargas manuales)
• TestNG → framework de testing

<dependencies>
    <!-- Selenium -->
    <dependency>
        <groupId>org.seleniumhq.selenium</groupId>
        <artifactId>selenium-java</artifactId>
        <version>4.27.0</version>
    </dependency>

    <!-- WebDriverManager -->
    <dependency>
        <groupId>io.github.bonigarcia</groupId>
        <artifactId>webdrivermanager</artifactId>
        <version>5.9.2</version>
    </dependency>

    <!-- TestNG -->
    <dependency>
        <groupId>org.testng</groupId>
        <artifactId>testng</artifactId>
        <version>7.10.2</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Por qué WebDriverManager (vs ChromeDriver manual)

Antes usaba ChromeDriver descargado manualmente.

El problema con ChromeDriver manual:

Tenías que:

1. Ir a https://chromedriver.chromium.org/
2. Descargar la versión que coincida con tu Chrome
3. Ponerlo en una carpeta
4. Configurar la ruta en el código:

   System.setProperty("webdriver.chrome.driver", "C:/drivers/chromedriver.exe");

El dolor:

• Chrome se actualiza automáticamente
• ChromeDriver queda viejo
• Los tests fallan con: "session not created: This version of ChromeDriver only supports Chrome version XX"
• Tenés que volver a descargar manualmente

Eso es mantenimiento innecesario.

La solución: WebDriverManager

WebDriverManager.chromedriver().setup();

Una línea. Listo.

Qué hace automáticamente:

1. Detecta tu versión de Chrome
2. Descarga el ChromeDriver correspondiente
3. Lo guarda en caché
4. Lo configura

Ventajas:

• Sin mantenimiento manual
• Sin rutas hardcodeadas
• Sin problemas de versionado
• Funciona en cualquier máquina (Windows, Mac, Linux)

Muchos tutoriales viejos todavía usan ChromeDriver manual.
WebDriverManager es el estándar moderno.

Por qué TestNG

Opciones de frameworks de testing para Java:

• JUnit
• TestNG
• Cucumber (BDD)

Por qué TestNG sobre JUnit:

JUnit está diseñado para unit testing (devs).
TestNG está diseñado para QA Automation.

Ventajas técnicas de TestNG:

1. DataProviders nativos
   Podés correr el mismo test con 50 sets de datos:

   @DataProvider
   public Object[][] usuarios() {
       return new Object[][] {
           {"user1", "pass1"},
           {"user2", "pass2"}
       };
   }

1. Ejecución paralela out-of-the-box
   Configurás en testng.xml, los tests corren en paralelo.
2. Grupos de tests
   Etiquetás: @Test(groups = {"smoke", "regression"})
   Ejecutás solo lo que necesitás.
3. Reportes mejores
   TestNG genera HTML automáticamente.
4. Control de dependencias
   Un test puede depender de otro.

Demanda del mercado:
Selenium + Java + TestNG es el stack más pedido.

JUnit se usa, pero TestNG tiene más features para automation.

Por qué NO Cucumber:

• Agrega complejidad (código Java + archivos Gherkin)
• Mantenimiento duplicado
• La mayoría de las empresas NO lo usan realmente
• Lo voy a considerar solo si una empresa específica lo pide

Empiezo con TestNG. Domino lo que más se usa.

Primer test

src/test/java/PrimerTest.java

import io.github.bonigarcia.wdm.WebDriverManager;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.Test;

public class PrimerTest {

    @Test
    public void abrirGoogle() {
        // Setup automático del driver
        WebDriverManager.chromedriver().setup();

        // Crear instancia del driver
        WebDriver driver = new ChromeDriver();

        // Abrir Google
        driver.get("https://www.google.com");

        // Obtener título
        String titulo = driver.getTitle();
        System.out.println("Título de la página: " + titulo);

        // Cerrar browser
        driver.quit();

        System.out.println("Test ejecutado correctamente");
    }
}

Después de agregar las dependencias: reload de Maven

Una vez que guardé el pom.xml y PrimerTest.java , los imports en PrimerTest.java seguían en rojo.

El problema: IntelliJ todavía no descargó las librerías.

La solución: hacer que Maven descargue las dependencias.

IntelliJ muestra un popup arriba a la derecha:
"Maven projects need to be imported"

Dos opciones:

• Click en "Load Maven Changes" (el ícono de reload en el popup)
• O click derecho en pom.xml → Maven → Reload project

Maven descarga las 3 dependencias (Selenium, WebDriverManager, TestNG).
Esto tarda 1-2 minutos la primera vez.

Una vez que termina: los imports dejan de estar en rojo y el código compila.

Ejecución del primer test

Ejecuté el test (click derecho en PrimerTest → Run).

Qué pasó:

• Chrome se abrió automáticamente
• Cargó Google
• Se cerró rápidamente

Consola:

Tests passed: 1 of 1 test – 13 sec 736 ms

Título de la página: Google
Test ejecutado correctamente

===============================================
Default Suite
Total tests run: 1, Passed: 1, Failures: 0, Skips: 0
===============================================

Process finished with exit code 0

Exit code 0 = éxito.

El test funcionó. Selenium abrió Chrome, obtuvo el título, lo imprimió y cerró el browser.

Advertencias en el log (y por qué no importan)

Aparecieron warnings rojos sobre SLF4J y CDP.

No son errores. El test pasó igual.

• SLF4J: Selenium busca un sistema de logging que no configuré. No afecta la ejecución.
• CDP: Chrome DevTools Protocol. Feature avanzada que no uso todavía.

Ambos se pueden resolver después con configuraciones opcionales. Por ahora: ignorar.

Lo importante: el test corrió y pasó.

Estado actual del proyecto

Tengo:

• Java 17 instalado
• Maven configurado
• Dependencias descargadas (Selenium, WebDriverManager, TestNG)
• Primer test funcionando

Próximo paso:

• Mejorar el test con assertions reales (verificar que el título sea exactamente "Google")
• Estructurar con Page Object Model
• Agregar más tests

Conclusión

Arranqué desde cero: estructura Maven limpia, dependencias básicas, primer test simple.

El test funcionó.

No hice nada complejo: solo abrí Google, imprimí el título y cerré el browser.

Pero este test confirma que el setup está bien:

• Java compila
• Maven gestiona dependencias
• Selenium interactúa con Chrome
• TestNG ejecuta tests

Esto es la base. Ahora puedo construir encima.

Próximo post:
Mejorar este test con assertions reales y empezar a estructurar con Page Object Model.

El laboratorio está listo. A construir.

🔗 Todo el código de esta serie está en: github.com/cesarbeassuarez/qa-automation-lab
📂 selenium-java

—

Si te interesó esto:

El contexto detrás de este laboratorio público: Por qué construyo en público.