Git para Ingenieros de QA

Por Que los QA Engineers Necesitan Git #

Todo proyecto profesional de automatizacion usa control de versiones. Git es el estandar de la industria. Como QA automation engineer, vas a:

• Almacenar codigo de test en repositorios junto al codigo de la aplicacion
• Crear branches para nuevos suites de test y funcionalidades
• Enviar pull requests para code review
• Resolver conflictos de merge cuando varias personas editan tests
• Usar el historial de Git para entender cuando y por que cambiaron los tests
• Integrarte con pipelines CI/CD que se disparan por eventos de Git

Comandos Esenciales de Git #

Configuracion Inicial #

# Configurar tu identidad
git config --global user.name "Tu Nombre"
git config --global user.email "tu.email@company.com"

# Clonar un repositorio
git clone https://github.com/company/test-automation.git
cd test-automation

# Verificar estado actual
git status

Comandos del Flujo Diario #

# Obtener ultimos cambios del remoto
git pull origin main

# Crear nueva branch para tu trabajo
git checkout -b feature/add-login-tests

# Verificar que archivos cambiaste
git status
git diff

# Agregar archivos especificos al staging
git add tests/login.spec.ts
git add tests/fixtures/users.json

# Commit con mensaje descriptivo
git commit -m "Agregar suite de tests de login con escenarios positivos y negativos"

# Push de tu branch al remoto
git push origin feature/add-login-tests

Viendo el Historial #

# Ver historial de commits
git log --oneline -20

# Ver que cambio en un commit especifico
git show abc1234

# Ver quien modifico cada linea de un archivo
git blame tests/login.spec.ts

# Encontrar cuando se agrego o modifico un test
git log --follow tests/checkout.spec.ts

Estrategia de Branching para Codigo de Test #

Convenciones de Nombres de Branch #

Usa nombres claros y descriptivos:

feature/add-checkout-tests      # Nuevo suite de tests
feature/POM-login-page          # Nuevo page object
fix/flaky-search-test           # Corregir test inestable
refactor/base-test-class        # Refactorizar codigo existente
chore/update-playwright-version # Actualizacion de dependencias

El Flujo de Feature Branch #

main ─────────────────────────────────────────
       \                              /
        feature/add-login-tests ─────

1. Crear branch desde main
2. Hacer cambios y commits
3. Push al remoto y abrir pull request
4. Obtener code review de companeros
5. CI ejecuta tus tests automaticamente
6. Merge despues de la aprobacion

Manteniendo tu Branch Actualizada #

# Mientras trabajas, main puede tener nuevos commits
git checkout main
git pull origin main
git checkout feature/add-login-tests
git rebase main

# O merge de main en tu branch
git merge main

El Proceso de Pull Request #

Creando un Buen PR para Codigo de Test #

Un buen pull request incluye:

Titulo: Descripcion clara de que tests se agregan/cambian

Agregar tests E2E de pagina de login con edge cases

Descripcion:

## Que
- Agregados 12 test cases para la pagina de login
- Cubre login positivo, credenciales invalidas, bloqueo de cuenta, SSO

## Cobertura de Tests
- Happy path: login valido con email/password
- Negativo: password incorrecto (3 intentos → bloqueo)
- Edge cases: SQL injection en campo email, XSS en password
- SSO: flujos OAuth de Google y GitHub

## Page Objects Agregados
- LoginPage: login(), forgotPassword(), socialLogin()
- DashboardPage: verifyWelcome(), logout()

## Como Ejecutar
npm run test:login

Checklist de Code Review para Codigo de Test #

Al revisar PRs de test, verifica:

• Tests tienen nombres claros y descriptivos
• Sin datos hardcodeados (usar fixtures o factories)
• Uso apropiado de page objects (sin selectores raw en tests)
• Aserciones especificas y significativas
• Tests independientes (sin dependencia de orden)
• Cleanup manejado (datos de test, estado del browser)
• Sin waits o sleeps innecesarios

Manejando Conflictos de Merge #

Los conflictos ocurren cuando dos personas editan el mismo archivo. En automatizacion, esto ocurre comunmente en:

• Page objects compartidos
• Archivos de configuracion de test
• Archivos de datos de prueba

Resolviendo un Conflicto #

# Cuando ves un conflicto despues de merge o rebase
# Git marca las secciones conflictivas:

<<<<<<< HEAD (tus cambios)
async login(email, password) {
  await this.page.fill('#email-v2', email);
}
=======
async login(email, password) {
  await this.page.fill('[data-testid="email"]', email);
}
>>>>>>> main (cambios entrantes)

# Resuelve eligiendo la version correcta o combinando ambas
async login(email, password) {
  await this.page.fill('[data-testid="email"]', email);
}

# Luego agrega y haz commit
git add tests/pages/login.page.ts
git commit -m "Resolver conflicto de merge: usar selector data-testid para email"

.gitignore para Proyectos de Test #

Un .gitignore apropiado previene archivos innecesarios:

# Resultados y reportes de test
test-results/
playwright-report/
allure-results/
allure-report/
coverage/

# Screenshots y videos de ejecuciones
screenshots/
videos/
traces/

# Dependencias
node_modules/
.venv/

# Archivos IDE
.vscode/
.idea/
*.swp

# Archivos de entorno con secretos
.env
.env.local

# Archivos de OS
.DS_Store
Thumbs.db

# Build output
dist/
build/

Git Hooks para Calidad de Tests #

Los git hooks ejecutan scripts automaticamente en eventos especificos de Git:

Pre-Commit Hook #

Ejecutar linting antes de cada commit:

#!/bin/sh
# .git/hooks/pre-commit
npx eslint tests/ --ext .ts,.js
if [ $? -ne 0 ]; then
  echo "Linting fallo. Corrige los problemas antes de hacer commit."
  exit 1
fi

Pre-Push Hook #

Ejecutar tests antes de hacer push:

#!/bin/sh
# .git/hooks/pre-push
npx playwright test --grep @smoke
if [ $? -ne 0 ]; then
  echo "Smoke tests fallaron. Corrige antes de hacer push."
  exit 1
fi

Git Avanzado para QA #

Guardando Trabajo en Progreso con Stash #

# Guardar cambios no commiteados temporalmente
git stash save "WIP: tests de checkout"

# Cambiar a otra branch para arreglar algo urgente
git checkout fix/flaky-login-test

# Regresar y restaurar tu trabajo
git checkout feature/checkout-tests
git stash pop

Cherry-Pick de una Correccion #

# Aplicar un commit especifico de otra branch
git cherry-pick abc1234

Bisect para Encontrar Cuando se Rompio un Test #

# Encontrar que commit introdujo un bug
git bisect start
git bisect bad           # Commit actual esta roto
git bisect good abc1234  # Este commit viejo funcionaba

# Git hace checkout de un commit intermedio — ejecuta tu test
npx playwright test tests/login.spec.ts

# Dile a Git el resultado
git bisect good  # o git bisect bad

# Repite hasta que Git encuentre el commit culpable
git bisect reset  # Cuando termines

Mejores Practicas de Colaboracion #

Guia de Mensajes de Commit #

# Buenos mensajes de commit
git commit -m "Agregar tests E2E de checkout para usuario invitado y registrado"
git commit -m "Corregir test inestable de busqueda: aumentar timeout de espera para respuesta API"
git commit -m "Refactorizar LoginPage: extraer metodos de llenado de formulario a BaseFormPage"

# Malos mensajes de commit
git commit -m "arreglar tests"
git commit -m "actualizar"
git commit -m "WIP"

Commits Atomicos #

Cada commit debe ser una unidad logica:

• Un commit por funcionalidad o correccion
• Los tests deben pasar despues de cada commit
• No mezclar cambios no relacionados

Ejercicio: Practica del Flujo de Git #

Practica el siguiente flujo de trabajo:

1. Clona un repositorio de tests (o crea uno nuevo)
2. Crea una branch feature/add-search-tests
3. Agrega un archivo tests/search.spec.ts con dos test cases
4. Haz commit con un mensaje descriptivo
5. Crea una segunda branch feature/add-filter-tests desde main
6. Modifica el mismo archivo de configuracion en ambas branches
7. Haz merge de ambas branches y resuelve cualquier conflicto
8. Ve el historial con git log --graph --oneline

Puntos Clave #

• Usa feature branches para todos los cambios de codigo de test
• Escribe mensajes de commit descriptivos explicando que y por que
• Siempre haz pull de los ultimos cambios antes de iniciar nuevo trabajo
• Maneja conflictos de merge entendiendo ambos cambios
• Usa .gitignore para mantener resultados y reportes fuera del repo
• Los git hooks automatizan verificaciones de calidad antes de commit y push