QA Engineer enfocado en automatización y SDET. Vengo del desarrollo full-stack, y uso ese criterio de ingeniería para construir automatización de calidad de punta a punta: frameworks E2E, de API y mobile, pipelines CI/CD con quality gates, performance, seguridad shift-left y testing de aplicaciones con IA.
🌱 Actualmente: profundizando en arquitectura de frameworks SDET y en el testing de sistemas no deterministas (LLMs).
El diferencial no es la herramienta: es poder demostrar cada afirmación.
- 🧬 Un dueño por riesgo. Selenium no reimplementa lo que ya prueba la API; Katalon no duplica la regresión de Selenium. Cada herramienta cubre el riesgo que le corresponde, y nada se prueba dos veces.
- 🚦 Los gates bloquean de verdad. Y verifico también su modo de fallo: un gate que nunca falla no prueba nada.
- 📐 Evidencia honesta. Cada repositorio distingue explícitamente lo que se ejecutó de lo que no:
| Significado | |
|---|---|
| 🟢 | Ejecutado y verificado. Hay salida real, reproducible con un comando. |
| 🔴 | No ejecutado en ese entorno (licencia, emulador o cuenta cloud). El código es real; la limitación se declara. |
No son siete tutoriales sueltos: es un producto financiero ficticio con sus siete capas de calidad, que se integran entre sí.
flowchart TB
api["🏦 transfer-api<br/>Spring Boot · idempotencia"]
web["🌐 web-banking-e2e<br/>Selenium · Cucumber"]
mob["📱 wallet-mobile<br/>Appium · Page Objects"]
kat["🔀 cross-channel<br/>Katalon · smoke"]
perf["⚡ performance-lab<br/>JMeter · SLOs como gate"]
tower["🗼 control-tower<br/>Jira/Xray · trazabilidad"]
plat["🚀 quality-platform<br/>Docker · K8s · GitLab CI"]
api -->|contrato| web
api -->|contrato| mob
api --> perf
web --> kat
mob --> kat
api --> kat
kat --> tower
perf --> tower
plat -.->|orquesta los quality gates| api
plat -.-> tower
classDef core fill:#1B5E20,stroke:#0d3b12,color:#ffffff,stroke-width:2px
classDef chan fill:#2E7D32,stroke:#1B5E20,color:#ffffff
classDef tool fill:#E8B341,stroke:#a97c1f,color:#1b2416
classDef infra fill:#0D1117,stroke:#E8B341,color:#E8B341,stroke-width:2px
class api core
class web,mob chan
class kat,perf,tower tool
class plat infra
| # | Repositorio | Qué demuestra | Evidencia | CI |
|---|---|---|---|---|
| 1 | nexo-transfer-api | API de transferencias: idempotencia, autorización por titularidad, trazabilidad · Spring Boot |
🟢 |  |
| 2 | nexo-web-banking-e2e | Framework UI mantenible: Page Object Model, esperas web-first · Selenium Cucumber |
🟢 |  |
| 3 | nexo-wallet-mobile | Abstracción de dos modos: la suite corre sin emulador · Appium |
🟢🔴 |  |
| 4 | nexo-cross-channel-regression | Smoke cross-channel + validador estático propio como gate · Katalon |
🟢🔴 |  |
| 5 | nexo-performance-lab | Hipótesis → capacidad medida (~460 rps); SLOs como gate · JMeter |
🟢 |  |
| 6 | nexo-quality-control-tower | Matriz requisito → prueba → resultado; gate ante requisitos sin cobertura · Jira/Xray |
🟢🔴 |  |
| 7 | nexo-quality-platform | Entorno reproducible; rolling update con 0 fallos · Docker K8s GitLab CI |
🟢 |  |
📌 Tres hallazgos que valen más que el código
- ⚡ El p99 se rompe antes que el p95. En el laboratorio de performance, a 300 usuarios el promedio decía
304 msy mentía: el p99 era1154 ms. La cola de la distribución es la alarma temprana, no el promedio. - 🚀 Un rolling update sin corte no es magia. Son tres líneas de manifiesto:
maxUnavailable: 0, dos réplicas y unareadinessProbedistinta de la liveness. Lo medí: 0 peticiones fallidas durante el despliegue. - 🕳️ El hueco más peligroso es el requisito que nadie prueba. Ninguna suite lo detecta — porque no existe. Por eso la torre de control falla el pipeline cuando un requisito no tiene ni una prueba.
Diez proyectos que recorren el ciclo de testing completo, de los fundamentos a las prácticas propias de un rol SDET. Cada uno con tests ejecutados, documentación técnica y CI.
🧱 Fundamentos — E2E · API · CI/CD · flakiness · visual & contract
| Proyecto | Foco | Stack |
|---|---|---|
| Framework E2E de UI | Page Object Model, fixtures, cross-browser | Playwright TypeScript |
| Testing de API | Contract testing, casos negativos, encadenamiento | Playwright Zod |
| Pipeline CI/CD | Quality gates, dos velocidades, matriz + sharding | GitHub Actions |
| Estabilidad y flakiness | Diagnóstico y erradicación: 85 % → 0 % | Playwright |
| Regresión visual & contract | Screenshots + Pact consumer-driven | Playwright Pact |
🚀 Avanzado (SDET) — performance · integración · DevSecOps · tooling · IA
| Proyecto | Foco | Stack |
|---|---|---|
| Performance & load testing | Escenarios de carga, thresholds como gate | k6 |
| Integración con dependencias reales | Postgres efímero, constraints y tipos reales | Testcontainers PostgreSQL |
| DevSecOps | Seguridad shift-left: SAST · SCA · DAST como gates | Semgrep npm audit |
| Tooling interno de QA | Test impact analysis + detección de flaky tests | TypeScript |
| Evals de aplicaciones con IA | Golden dataset, scorers y umbral como gate | LLM testing |
Testing & Automatización
Performance & Confiabilidad
Lenguajes
CI/CD & Infraestructura
Calidad, Seguridad & IA
«Un gate que nunca falla no prueba nada.»
