Juan Diego Vera

Disponible para nuevos retos · Remoto

Hola, mi nombre es Juan Diego Vera.

QA Automation Engineer / SDET

Especialista en Ingeniería de Software · énfasis en Pruebas · Universidad Autónoma de Manizales

Juan Diego Vera Godoy, QA Automation Engineer / SDET

Construyo automatización de pruebas en la que los equipos confían: frameworks desde cero para APIs y UI, integrados a CI/CD y con trazabilidad de requisito a defecto. Tres de mis cinco años fueron en software de salud regulado por la FDA para Roche.

Ver proyectos Descargar CV ↓ LinkedIn ↗
  • 📍 Medellín, Colombia
  • 🗣️ Español · English C1 · Français
  • 🧬 Ingeniero biomédico
5años en automatización de pruebas
3años en software de salud regulado por la FDA (Roche · HL7)
4frameworks públicos con CI y reportes en vivo
6defectos reales encontrados y documentados

Pruébalo tú

Mi test runner, en tu navegador

Escribe un comando y mira una ejecución con los escenarios reales de mis repositorios, o lanza una prueba de UI que llena un formulario frente a ti.

  • run all simula las 4 suites (94 escenarios reales)
  • demo una prueba de UI estilo Playwright en vivo
  • defects los defectos reales que encontré
  • lab el laboratorio con 11 pruebas reales
jdvg@portfolio: ~/test-runner
run-portfolio-suites
✓ fhir-api-automation · 19 passed
✓ playwright-hybrid · 36 passed
✓ dotnet-api-automation · 21 passed
✓ java-selenium-cucumber · 18 passed

Es interactiva: escribe un comando o toca uno.

Portafolio

Proyectos que puedes ejecutar hoy

Cada proyecto corre en GitHub Actions y publica su reporte en vivo. Mi código profesional está bajo acuerdos de confidencialidad, así que aquí muestro cómo diseño frameworks con sistemas públicos.

Salud · Interoperabilidad 19 escenarios

FHIR R4 API Automation

Pruebas BDD del estándar HL7 FHIR R4, el idioma con el que hospitales y laboratorios intercambian datos clínicos. Un test que pasa debe probar que el dato es clínicamente correcto: paciente, código y unidad.

  • Versionado y vread; 410 Gone vs 404; integridad referencial (409)
  • Signos vitales con LOINC + UCUM y errores con OperationOutcome
  • Hallazgo: la caché de búsquedas del servidor ocultaba datos recién creados
  • C#
  • .NET 10
  • Reqnroll
  • Firely SDK
  • Allure
Reporte en vivo ↗
API + UI híbrido 36 ejecuciones

Playwright Hybrid Framework

Preparo y verifico los datos por API y pruebo el comportamiento por UI, en Chromium, Firefox y WebKit. Rápido, independiente, y confirma lo que llegó al backend, no solo lo que muestra la pantalla.

  • Sesión de admin por API (storage state) y limpieza automática
  • Accesibilidad WCAG 2.1 AA con axe-core como control de regresión
  • 2 defectos: el inicio solo muestra 3 cuartos; un cuarto borrado tumba la página (API 500)
  • Playwright
  • TypeScript
  • axe-core
  • GitHub Actions
Reporte en vivo ↗
API · BDD 21 escenarios

.NET API Automation Framework

Framework BDD con una librería cliente separada de las pruebas, datos aislados para ejecutar en paralelo, validación de contratos con JSON Schema y tiempos de respuesta.

  • Plan de pruebas (ISO 25010), matriz de trazabilidad y reportes de bug
  • 4 defectos documentados con @known-defect y evidencia curl
  • Diagnóstico y corrección de un test intermitente por datos aleatorios
  • C#
  • Reqnroll
  • NUnit
  • RestSharp
  • JSON Schema
Reporte en vivo ↗
Java · UI + API 18 escenarios

Java Selenium Cucumber Framework

Selenium WebDriver y RestAssured con Cucumber. Lo empecé en 2024 y lo modernicé: Java 21, inyección de dependencias, ejecución en paralelo y locators estables.

  • Total = subtotal + impuesto verificado con BigDecimal
  • Arreglé un runner que en Linux nunca ejecutaba los tests de UI
  • Sin estado estático: cada escenario tiene su propio navegador
  • Java 21
  • Selenium 4
  • Cucumber
  • RestAssured
Reporte en vivo ↗

Laboratorio en vivo

Ejecuta mis pruebas de UI con un clic

Una app de citas médicas y un runner de pruebas al estilo Playwright. Presiona un botón y mira cómo las pruebas inician sesión, agendan y cancelan citas de verdad; al final descargas el reporte en HTML, JUnit XML o JSON.

  • 4 suites: smoke, regresión, negativos y todo (11 pruebas)
  • Inyecta un bug y mira cómo la regresión lo detecta
  • Las mismas pruebas corren con Playwright en CI, con su reporte oficial
Abrir el laboratorio → Reporte de Playwright ↗
medicita.lab ✓ el paciente inicia sesión ✓ el paciente agenda una cita de principio a fin ✓ filtra los médicos por especialidad ✗ un horario ya reservado no se puede volver a reservar expect(locator).toBeDisabled() failed · Expected: disabled · Received: enabled ✓ el paciente cancela una cita 6 passed · 1 failed · bug: double-booking

Calidad en vivo

Mis pruebas corren todos los días

Datos reales de GitHub Actions: cada repositorio se ejecuta en cada cambio y cada mañana entre semana. Este panel se regenera a diario.

Juego

Encuentra el bug

Este checkout tiene 5 defectos sembrados a propósito. Úsalo como lo haría un tester curioso: cada bug que provoques se convierte en un reporte con la prueba automatizada que lo atraparía.

https://shop.bug-hunt.test/cart
Subtotal
Descuento
Total

    ¿Necesitas pistas?
    • ¿Qué pasa si un cupón se usa más de una vez?
    • ¿Las cantidades tienen límites?
    • Revisa los centavos con varias unidades del producto más barato.
    • ¿Qué hace un usuario impaciente con el botón Pagar?
    • ¿Se puede comprar… nada?

    Expedientes

    Bugs difíciles, resueltos con evidencia

    Casos reales de estos proyectos. No asumo, demuestro: cada hipótesis se confirma o se descarta con una prueba.

    Defecto de producto Los cuartos nuevos nunca aparecían en el inicio Playwright · TypeScript
    1. Síntoma El test "un cuarto creado por API aparece en el inicio" fallaba en Chromium, Firefox y WebKit.
    2. Hipótesis ¿Caché del navegador o del servidor? ¿Mi test buscaba mal la tarjeta?
    3. Prueba Intercepté la red: la página recibía 4 cuartos de /api/room pero solo pintaba 3. Busqué en el JavaScript publicado.
    4. Causa El frontend hace rooms.slice(0, 3): los cuartos a partir del cuarto nunca se ofrecen a los huéspedes.
    5. Resultado BUG-001 documentado con evidencia y un test @known-defect; el chequeo híbrido ahora compara las tarjetas con la API.
    Reporte en vivo ↗
    Test intermitente La búsqueda pasaba una vez y luego fallaba siempre FHIR · C#
    1. Síntoma "Buscar paciente por apellido y fecha de nacimiento" pasaba en la primera corrida y fallaba en todas las siguientes.
    2. Hipótesis El servidor HAPI FHIR reutiliza resultados de búsquedas idénticas recientes.
    3. Prueba Lo reproduje con curl: creé un paciente y la misma búsqueda no lo devolvía; con Cache-Control: no-cache sí aparecía.
    4. Causa Caché de búsquedas del servidor: comportamiento documentado de HAPI, no un defecto, pero oculta datos recién creados.
    5. Resultado El cliente envía Cache-Control: no-cache en cada búsqueda → 14 corridas seguidas en verde.
    Reporte en vivo ↗
    Entorno Chrome se tragaba los clics Java · Selenium
    1. Síntoma El carrito quedaba en 0 tras agregar productos y el menú de logout nunca abría. Solo en Chrome.
    2. Hipótesis ¿Locators incorrectos tras un cambio del sitio?
    3. Prueba Volqué todos los atributos data-test de cada página: todos los locators existían. La hipótesis quedó descartada.
    4. Causa Las credenciales públicas de SauceDemo disparan el aviso "contraseña filtrada" de Chrome, que bloquea la página.
    5. Resultado Gestor de contraseñas y detección de filtraciones desactivados con preferencias de Chrome en el DriverFactory.
    Reporte en vivo ↗
    Test intermitente StaleElementReferenceException al quitar del carrito Java · Selenium
    1. Síntoma Un escenario fallaba de forma intermitente con StaleElementReferenceException.
    2. Hipótesis React vuelve a dibujar la lista entre que Selenium encuentra la fila y le hace clic.
    3. Prueba El stack trace apuntaba a la búsqueda del producto dentro del carrito, justo después de navegar.
    4. Causa Referencias a elementos que React ya había reemplazado.
    5. Resultado Búsqueda y clic reintentados juntos ignorando elementos obsoletos, y espera a que la lista tenga un elemento menos → 8 corridas en verde.
    Reporte en vivo ↗
    Test intermitente Un null aleatorio rompía la validación .NET · C#
    1. Síntoma "Crear una reserva" fallaba a veces en la validación de esquema JSON.
    2. Hipótesis Los datos aleatorios generan un caso que el esquema no acepta.
    3. Prueba El error del esquema señalaba el campo exacto: /additionalneeds: Value is "null" but should be "string".
    4. Causa El generador a veces enviaba additionalneeds: null y la API lo devolvía igual.
    5. Resultado El campo opcional se omite en vez de enviarse como null. Verificado forzando el caso en los 21 escenarios y con 37 corridas repetidas.
    Reporte en vivo ↗

    Cómo trabajo

    Calidad que se puede demostrar

    Arrange por API, prueba por UI

    Los datos se crean y verifican por API: pruebas rápidas, independientes y que confirman lo que de verdad se guardó.

    Una prueba debe poder fallar

    Antes de confiar en un test verde, rompo a propósito lo que verifica. Si no falla, no está probando nada.

    Defectos visibles, no escondidos

    Un bug conocido se documenta con evidencia y su propio test, que falla a propósito cuando se corrige.

    Trazabilidad de punta a punta

    Requisito → escenario → defecto. En salud aprendí que la calidad es poder demostrar qué se probó y por qué.

    Experiencia

    Trayectoria

    1. Dic 2024 — Hoy

      Software QA Engineer / SDET · Solvo Global

      Diseñé desde cero un framework híbrido de automatización API + UI (C#, NUnit, Playwright, RestSharp) con ~300 pruebas, que redujo la regresión de ~4 horas manuales a menos de 30 minutos (la suite de API corre en ~4 minutos). Integrado a Azure DevOps con resultados en Qase.

    2. Sep 2021 — Dic 2024

      Test Automation Engineer · Globant (cliente: Roche)

      Automatización backend y de integraciones HL7 en software de salud regulado por la FDA, con .NET y SpecFlow; evidencia de pruebas para los releases, selección de herramientas y code reviews.

    3. Ene 2021 — Sep 2021

      Front End Developer Trainee · Acamica

      HTML, CSS y JavaScript: la base que hoy me ayuda a escribir locators robustos y a hablar el idioma de los desarrolladores.

    Habilidades

    Stack

    Lenguajes

    • C# / .NET
    • TypeScript
    • Java
    • JavaScript
    • SQL

    UI

    • Playwright
    • Selenium
    • Appium
    • POM
    • Screenplay

    API

    • REST
    • SOAP
    • RestSharp
    • RestAssured
    • Postman
    • JSON Schema

    BDD / Test

    • Reqnroll
    • SpecFlow
    • Cucumber
    • NUnit
    • JUnit
    • TestNG

    CI/CD

    • Azure DevOps
    • GitHub Actions
    • Git
    • SonarQube
    • Allure
    • Qase
    • Jira

    Dominio y calidad

    • HL7 FHIR
    • LOINC / UCUM
    • ISO/IEC 25010
    • WCAG 2.1
    • JMeter
    • Agile / Scrum

    Formación

    Especialista · Posgrado

    Especialización en Ingeniería de Software con énfasis en Pruebas · Universidad Autónoma de Manizales · 2025

    • Modelos de calidad ISO/IEC 25000 (SQuaRE) y 25010
    • ISO 9000-3 e ISO/IEC 33000 (evaluación de procesos)
    • Requisitos funcionales y no funcionales; pruebas de carga y rendimiento (JMeter)
    • Diseño de automatización con Page Object Model y Screenplay

    Ingeniería Biomédica (Bioingeniería) · Universidad de Antioquia · 2021

    ¿Buscas un SDET que eleve la calidad de tu equipo?

    Hablemos. Respondo en español, inglés o francés.

    Escríbeme Descargar CV ↓ LinkedIn ↗ GitHub ↗