Un Scale-up de pagos con 90 personas y 22 ingenieros estuvo a punto de perder a su cliente más grande por un incidente en producción: un cambio aparentemente menor en el flujo de cobro recurrente rompió el reintento automático de tarjetas vencidas. Nadie lo detectó porque la regresión se hacía a mano, el equipo iba apurado y ese flujo no estaba automatizado. El parche tardó once horas, costó una penalización contractual y, sobre todo, costó confianza. El VP Engineering pidió contratar QA. La primera reacción del área de finanzas fue contratar "un tester" lo más barato posible. Esa decisión, repetida cientos de veces en empresas tech, es exactamente el error que este reporte busca evitar.
Contratar QA no es contratar a alguien que rompa cosas ni un costo que se minimiza. Es contratar a quien protege el time-to-market: la persona que permite al equipo desplegar rápido sin miedo, porque hay una red de pruebas que atrapa el defecto antes de que llegue al cliente. Este reporte arma el marco completo para CTOs, Engineering Managers y Heads of Quality: la diferencia real entre QA manual, QA automation, SDET y QA Lead; las herramientas que importan en 2026; qué es shift-left testing y cómo cambia el perfil que necesita; las métricas con las que un senior real habla; las señales para distinguir seniority verdadero de falso senior; los errores comunes al contratar; cuándo conviene sumar un QA Lead; una banda salarial referencial; y cómo IT Workers encuentra a estos perfiles vía hunting de talento pasivo.
Más de tres mil palabras escritas con una sola regla: recomendar lo que aplica al lector que contrata, no lo que conviene al autor. Sin venta forzada y sin promesas mágicas.
¿Necesitas un QA Engineer o QA Lead senior y no encuentras al perfil correcto?
IT Workers entrega una terna calificada en 4 días hábiles, con garantía de 90 días y fee solo por éxito. Vamos por el QA que hoy trabaja feliz en otra empresa, no por el que está postulando.
Solicitar candidatos WhatsApp directo1. QA Engineer, QA automation, SDET y QA Lead: cuál necesitas realmente
El primer error al contratar calidad es buscar un título sin entender qué problema resuelve cada perfil. Bajo el paraguas de quality assurance conviven cuatro perfiles distintos, con habilidades, sueldos y propósitos diferentes. Contratar el equivocado es caro: un SDET haciendo prueba manual se aburre y se va; un tester manual al que se le exige construir infraestructura de automatización fracasa y deja la suite abandonada. La empresa debe elegir el perfil que ataca su cuello de botella real.
QA Engineer
Define casos, riesgos y cobertura. Combina prueba exploratoria con automatización. Decide qué probar y cómo, sin necesariamente construir toda la infraestructura. El perfil base de un equipo de calidad maduro.
QA Automation Engineer
Se especializa en automatizar pruebas sobre frameworks como Cypress, Playwright o Selenium. Mantiene las suites, reduce flaky tests y las integra al pipeline. Su valor está en la regresión confiable y veloz.
QA Lead
Lidera la estrategia de calidad transversal a varios squads. Elige el stack, define el career ladder de QA, mentorea al equipo y reporta métricas de calidad a la dirección. Liderazgo técnico con visión de negocio.
La regla práctica: si el problema es que la regresión manual ya no escala, necesita un QA automation engineer. Si el problema es que no hay infraestructura de testing ni datos de prueba confiables, necesita un SDET. Si el problema es que cada squad prueba a su manera y la dirección no tiene visibilidad, necesita un QA Lead. Si simplemente necesita criterio y estrategia de calidad para un equipo chico, un QA Engineer senior que ejerza liderazgo técnico suele bastar.
2. Por qué el QA no es "el que rompe cosas" sino quien protege el time-to-market
La cultura popular pinta al QA como el aguafiestas que encuentra problemas y frena los lanzamientos. Es una caricatura peligrosa, porque lleva a tratar la calidad como un costo a minimizar en lugar de una palanca de velocidad. La realidad madura es la inversa: un buen ingeniero de calidad es lo que permite desplegar más rápido, no más lento.
El mecanismo es simple. Cuando no hay red de pruebas confiable, cada despliegue es un acto de fe: el equipo va lento, prueba a mano, posterga los cambios riesgosos y vive con miedo de romper producción. Cuando hay una suite automatizada que cubre los flujos críticos de negocio, integrada al pipeline, el equipo despliega varias veces al día con confianza, porque sabe que si algo se rompe, la red lo atrapa antes del cliente. El QA, bien entendido, es quien construye y mantiene esa red. Por eso el indicador de éxito de un buen QA no es cuántos bugs encuentra, sino cuántos bugs no llegan a producción y cuánto más rápido entrega el equipo gracias a su trabajo.
Un buen QA no es el que rompe cosas. Es el que protege tu time-to-market: deja que el equipo despliegue rápido sin miedo, porque la red de pruebas atrapa el defecto antes de que llegue al cliente. Contratar QA barato sin estrategia no ahorra plata; la posterga hasta que estalla en producción.
Pablo Herrera · Founder & IT Headhunter en IT WorkersEl costo invisible de no tener QA
La ausencia de calidad no se ve en una línea del presupuesto; se ve en incidentes, en developers apagando incendios en lugar de construir, en clientes que se van sin avisar y en una velocidad de entrega que se desploma a medida que el producto crece. Una empresa con buena calidad de software gasta menos en soporte reactivo, retiene mejor a sus clientes y libera a sus ingenieros para crear valor. Ese costo invisible es el verdadero argumento de negocio para contratar bien la función de calidad, y se relaciona directamente con el costo oculto de un puesto tech vacante cuando la vacante de QA se posterga.
3. Herramientas reales: Cypress, Playwright, Selenium, Appium, k6
Las herramientas no hacen al ingeniero, pero un QA automation senior real domina un stack moderno y, más importante, sabe cuándo usar cada una. En 2026 el panorama de testing automatizado se concentra en pocas herramientas de referencia que conviene reconocer al evaluar un candidato.
- Playwright: el framework de automatización web que más creció. Rápido, multi-navegador, con auto-waiting que reduce flaky tests. Se volvió la elección por defecto para proyectos nuevos.
- Cypress: muy popular para pruebas end-to-end de front-end, con excelente experiencia de desarrollo y debugging. Fuerte en aplicaciones de una sola página.
- Selenium: el estándar histórico y todavía omnipresente. Muchas empresas tienen suites heredadas en Selenium; un senior debe saber mantenerlas y, cuando conviene, migrarlas.
- Appium: la referencia para automatización de aplicaciones móviles nativas e híbridas en iOS y Android.
- k6, Gatling, JMeter: prueba de carga y rendimiento. Imprescindibles para validar que el sistema aguanta el tráfico esperado antes de un evento de alto volumen.
- Postman, REST Assured, pytest: prueba de API, la capa más rentable de automatizar por su estabilidad y velocidad.
La señal importante no es que el candidato liste herramientas, sino que explique por qué elegiría una sobre otra en un contexto concreto. Un senior real dirá, por ejemplo, que prefiere Playwright sobre Selenium para un proyecto nuevo por su manejo de esperas, pero mantendría Selenium en una suite heredada estable en lugar de migrarla sin justificación de negocio. Ese criterio de trade-offs es lo que separa al ingeniero de calidad del operador de herramientas.
4. Shift-left testing y testing en CI/CD: el cambio que define el perfil
El cambio más importante de la última década en calidad de software se llama shift-left testing: mover la prueba hacia la izquierda del ciclo de desarrollo. En el modelo antiguo, la calidad era una compuerta al final: los developers terminaban, "tiraban el código por encima del muro" y un área de QA separada lo probaba antes de salir a producción. Ese modelo produce demoras, fricción y la mentalidad tóxica de que la calidad es problema de otro.
En el modelo shift-left, la calidad se construye desde el inicio. El QA participa en el refinamiento de las historias de usuario, ayuda a definir los criterios de aceptación, escribe pruebas automatizadas junto al código y opera dentro del pipeline de integración continua. Cada cambio que un developer sube dispara automáticamente las pruebas; si algo falla, el merge se bloquea antes de llegar a producción. Esto cambia radicalmente el perfil de QA que la empresa necesita: ya no busca a alguien que ejecute casos al final, sino a un ingeniero que colabora con developers, entiende arquitectura y sabe programar.
Por qué shift-left ahorra dinero real: el costo de corregir un defecto crece de forma dramática a medida que avanza el ciclo. Un bug detectado en el diseño cuesta una fracción de lo que cuesta el mismo bug en código, y este último cuesta una fracción de lo que cuesta en producción, donde se suman incidentes, soporte, penalizaciones y pérdida de confianza. Contratar un QA con mentalidad shift-left no es un gasto de calidad: es una decisión financiera que reduce el costo total de los defectos del producto.
Testing en CI/CD: la pirámide de pruebas
Un QA senior moderno razona con la pirámide de testing: muchas pruebas unitarias rápidas en la base, una capa intermedia de pruebas de integración y API, y pocas pruebas end-to-end en la cima, porque son las más lentas y frágiles. Integrar esta pirámide en el pipeline de CI/CD (GitHub Actions, GitLab CI, Jenkins) es lo que permite validar cada cambio en minutos. Un candidato que propone automatizar todo a nivel end-to-end, sin entender la pirámide, está mostrando una señal de inmadurez técnica que conviene detectar en la entrevista.
5. Métricas de calidad: cobertura útil, escape rate, flaky tests, lead time
Un QA senior real habla con métricas, no con sensaciones. Pedir al candidato cómo mediría el éxito de su trabajo es una de las preguntas más reveladoras de seniority. Estas son las cuatro métricas que importan al evaluar y al contratar.
| Métrica | Qué mide | Por qué le importa al decisor | Señal de alerta |
|---|---|---|---|
| Cobertura útil | Qué porcentaje de los flujos críticos de negocio está realmente probado | Distingue cobertura de líneas (vanidad) de cobertura de riesgo (valor real) | Presumir 90% sin distinguir flujo crítico de código trivial |
| Escape rate de defectos | Cuántos bugs llegan a producción frente a los detectados antes | Es el indicador directo de cuánto protege el QA al cliente | No medirlo o no saber su valor actual |
| Tasa de flaky tests | Pruebas que fallan de forma intermitente sin causa real | Una suite poco confiable erosiona la confianza y se termina ignorando | Convivir con flaky tests en lugar de atacarlos |
| Lead time de testing | Cuánto demora validar un cambio desde que está listo | Mide el impacto del QA en la velocidad de entrega del equipo | Pruebas que tardan horas y frenan los despliegues |
La trampa más común es el candidato que presume porcentaje de cobertura como única métrica. La cobertura de líneas es fácil de inflar (probar código trivial sube el número sin proteger nada) y fácil de presumir. El senior real prioriza por riesgo: prefiere 70% de cobertura concentrada en los flujos que mueven dinero o que rompen al cliente, antes que 95% de cobertura repartida en código irrelevante. Si quiere referencia adicional de cómo razonar productividad de ingeniería con métricas, vale revisar el marco de métricas de productividad de ingeniería con DORA y SPACE.
6. Señales de seniority real vs falso senior en QA
El mercado de QA está lleno de perfiles que acumulan años sin acumular seniority. Distinguir al senior real del falso senior es la habilidad más valiosa al contratar calidad, y se entrena con preguntas que obligan a mostrar criterio, no a recitar herramientas.
Cómo se comporta un senior real
- Piensa en riesgo, no en porcentaje: prioriza qué probar según impacto y probabilidad de fallo.
- Decide qué automatizar y qué dejar exploratorio, evitando suites frágiles que nadie mantiene.
- Ataca flaky tests de forma sistemática porque entiende que una suite poco confiable es peor que no tenerla.
- Integra calidad en CI/CD y conversa de arquitectura con developers de igual a igual.
- Traduce calidad a lenguaje de negocio: incidentes, costo de defectos, velocidad de entrega.
- Demuestra mentalidad shift-left: participa desde el refinamiento, no espera el producto terminado.
Las banderas rojas del falso senior
El falso senior describe su trabajo en términos de actividad (cuántos casos corre, cuántos bugs reporta) en lugar de impacto (qué riesgo controla). Se traba al justificar por qué eligió una herramienta sobre otra. No conoce el escape rate de su equipo actual. Cree que más automatización siempre es mejor, sin considerar el costo de mantención. Y describe su rol como una compuerta separada del equipo de desarrollo en lugar de una función colaborativa. Una entrevista bien diseñada, que pida diseñar una estrategia de prueba para un producto concreto, deja estas banderas a la vista en minutos. El marco general para evaluar candidatos tech sin ser técnico está en cómo evaluar candidatos tech siendo no técnico.
¿Quieres una terna de QA senior evaluada por criterio, no por currículum?
Diseñamos la búsqueda según tu cuello de botella de calidad y entrevistamos por estrategia, métricas y seniority real. Terna en 4 días hábiles, garantía de 90 días, fee solo por éxito. 4.9/5 con 13 reseñas en Google.
Agendar una reunión7. Errores comunes al contratar QA y cuándo necesitas un QA Lead
Los errores al contratar calidad se repiten con claridad. Reconocerlos antes de abrir la búsqueda ahorra meses y dinero.
Error 1: confundir QA con tester manual barato
El más caro de todos. La empresa necesita ingeniería de calidad (automatización, estrategia, integración en CI/CD) pero contrata por precio a alguien que solo ejecuta casos manuales. El resultado es una falsa sensación de cobertura: hay un QA en el organigrama, pero la regresión sigue siendo manual, no escala y los defectos siguen llegando a producción. Calidad barata sin estrategia no ahorra; posterga el costo hasta que estalla.
Error 2: pedir un SDET para tareas de QA manual
El error inverso. La empresa contrata a un perfil caro y altamente técnico para un rol donde solo necesita ejecución de casos. El SDET se aburre en semanas, no usa sus habilidades y se va al primer acercamiento de otra empresa. Sobre-contratar el perfil es tan dañino como sub-contratarlo.
Error 3: contratar el título de moda en lugar del perfil que resuelve el problema
SDET suena más impresionante que QA Engineer, pero no toda empresa necesita un SDET. Contratar por el título de moda, sin diagnosticar el cuello de botella real, lleva a pagar de más por habilidades que no se usan, o a contratar un perfil que no encaja con la madurez del equipo.
¿Cuándo un equipo necesita un QA Lead?
La señal clara es tener tres o más QA Engineers, estrategia de calidad caótica entre squads, o una dirección sin visibilidad de métricas agregadas. Por debajo de tres QA, normalmente basta con un QA Engineer senior que ejerza liderazgo técnico sin carga de gestión. Contratar un QA Lead demasiado pronto sobrecarga el rol con gestión inexistente y termina con un líder aburrido; contratarlo demasiado tarde deja al equipo sin estándar común y multiplica la deuda de calidad. La decisión de cuándo sumar liderazgo de calidad se relaciona con la lógica de cuándo contratar al primer Engineering Manager del equipo.
8. Banda salarial referencial y cómo IT Workers encuentra al QA correcto
Los rangos referenciales que siguen son estimaciones de mercado 2026 elaboradas en base a procesos gestionados por IT Workers y no constituyen una oferta ni una garantía de compensación para ningún rol o empresa específica. Cada empresa define sus propias bandas según su compensation philosophy, etapa y mercado objetivo.
| Perfil | Rango referencial (CLP) | Foco principal | Escasez en el mercado |
|---|---|---|---|
| QA Manual | $1.100.000 – $1.800.000 | Ejecución de casos y prueba exploratoria | Baja |
| QA Automation Engineer | $1.800.000 – $3.000.000 | Suites automatizadas y regresión confiable | Media |
| SDET | $2.800.000 – $4.200.000 | Infraestructura de testing y código de calidad | Alta |
| QA Lead | $3.500.000 – $5.500.000 | Estrategia transversal y liderazgo de calidad | Alta |
Los rangos varían por industria, stack, modalidad (el trabajo remoto en USD eleva el piso) y por la escasez del perfil específico. Para detalle por nivel, conviene revisar la renta de un QA Automation Engineer y, para roles cercanos del equipo de ingeniería, la renta de un Backend Developer, la renta de un Full Stack Developer y la renta de un Engineering Manager. La visión agregada de bandas por rol está en la guía salarial tech 2026.
Cómo IT Workers encuentra al QA correcto
Los mejores QA Engineers y QA Leads casi nunca están buscando trabajo: están trabajando felices en otra empresa, resolviendo problemas interesantes, y no postulan a avisos. Publicar una oferta y esperar produce un pool de candidatos disponibles, que no es lo mismo que los mejores candidatos. IT Workers trabaja con hunting de talento pasivo: identificamos a esos profesionales específicos, les presentamos el proyecto, el equipo y el desafío técnico de calidad, y los entusiasmamos a evaluar un cambio que no estaban buscando. No esperamos que llegue gente; vamos por la persona que resuelve el cuello de botella exacto de la empresa.
El modelo de IT Workers para roles de QA
- Terna calificada: tres candidatos evaluados por criterio y métricas, en 4 días hábiles.
- Hunting pasivo: vamos por el QA que hoy trabaja feliz en otra empresa.
- Garantía 90 días: si la contratación no resulta, reponemos la búsqueda.
- Fee solo por éxito: se paga cuando hay contratación, no por buscar.
- Evaluación real: entrevistamos por estrategia, herramientas y seniority, no por currículum.
Para entender por qué el hunting especializado supera a una bolsa de empleo o a un recruiter genérico en estos perfiles, vale revisar la comparación entre reclutamiento tech especializado y consultora de recursos humanos. Y si necesita un líder técnico que defina la estrategia de calidad a nivel ejecutivo, el camino natural es contratar un CTO o líder técnico que ordene la función completa.
9. FAQ: 10 preguntas que recibimos de CTOs y Engineering Managers
¿Cuál es la diferencia entre QA Engineer, QA automation, SDET y QA Lead?
Un QA Engineer diseña y ejecuta estrategia de prueba: define casos, riesgos y cobertura, y combina prueba exploratoria con prueba automatizada. Un QA automation engineer se especializa en construir y mantener suites automatizadas sobre frameworks como Cypress, Playwright o Selenium. Un SDET (Software Development Engineer in Test) es un perfil que programa al nivel de un developer y construye la infraestructura de testing, fixtures, mocks y pipelines. Un QA Lead lidera la estrategia de calidad de varios squads, define el career ladder de testing, elige herramientas y reporta métricas de calidad a la dirección. La empresa debe contratar el perfil que resuelve su cuello de botella real, no el título de moda.
¿Por qué no basta con contratar un tester manual barato?
Un tester manual ejecuta casos definidos por otra persona y verifica que la aplicación se comporte como se espera, sin construir automatización ni estrategia. Sirve para validación puntual, pero no escala: cuando el producto crece, el equipo no puede regresionar todo manualmente en cada despliegue. Un QA Engineer senior diseña una estrategia que protege el time-to-market: automatiza la regresión crítica, define qué se prueba en cada capa y libera a los developers para que avancen sin miedo a romper algo en producción. Contratar testing barato sin estrategia produce deuda de calidad que estalla justo cuando el negocio necesita acelerar.
¿Qué herramientas debería dominar un QA automation senior en 2026?
Un QA automation senior en 2026 domina al menos una herramienta de automatización web moderna (Playwright o Cypress, con Selenium como base heredada en muchas empresas), una de automatización móvil (Appium para escenarios nativos), una de prueba de carga y rendimiento (k6, Gatling o JMeter), y una de prueba de API (Postman, REST Assured o pytest). Igual de importante que la herramienta es la práctica: integrar las suites en CI/CD (GitHub Actions, GitLab CI, Jenkins), manejar datos de prueba, reducir flaky tests y reportar resultados accionables. La herramienta es reemplazable; el criterio para decidir qué automatizar y qué no, no lo es.
¿Qué es shift-left testing y por qué cambia el perfil de QA que necesito?
Shift-left testing significa mover la calidad hacia la izquierda del ciclo de desarrollo: en lugar de probar al final, justo antes de salir a producción, la calidad se construye desde el diseño y el código. En la práctica, el QA participa en el refinamiento de historias, define criterios de aceptación, escribe pruebas automatizadas junto al código y opera dentro del pipeline de CI/CD. Cambia el perfil porque ya no se busca a alguien que ejecute casos al final, sino a un ingeniero que colabora con developers, entiende arquitectura y sabe programar. Un QA con mentalidad shift-left reduce el costo de los defectos: un bug detectado en diseño cuesta una fracción del mismo bug en producción.
¿Qué métricas debería pedirle a un candidato a QA senior?
Un QA senior real habla con métricas, no con sensaciones. Las cuatro más relevantes son: cobertura de prueba útil (no solo porcentaje de líneas, sino cobertura de flujos críticos de negocio), escape rate de defectos (cuántos bugs llegan a producción frente a los detectados antes), tasa de flaky tests (pruebas que fallan de forma intermitente y erosionan la confianza en la suite) y lead time de testing (cuánto demora validar un cambio desde que está listo). Un candidato que solo presume porcentaje de cobertura, sin distinguir cobertura útil de cobertura inflada, es una señal de seniority aparente. El senior real prioriza riesgo, no porcentaje.
¿Cómo distingo un QA senior real de un falso senior?
Un falso senior acumula años ejecutando casos manuales o manteniendo suites que otra persona diseñó, y describe su trabajo en términos de actividad (cuántos casos corre) en lugar de impacto (qué riesgo controla). Un senior real piensa en estrategia: decide qué automatizar y qué dejar exploratorio, diseña la pirámide de testing, reduce flaky tests, integra calidad en CI/CD y conversa con developers de igual a igual sobre arquitectura. En la entrevista, el falso senior se traba al explicar por qué eligió una herramienta sobre otra o cómo mediría el ROI de una suite; el senior real tiene opinión fundada, reconoce trade-offs y prioriza por riesgo de negocio.
¿Cuándo un equipo necesita un QA Lead y no solo más QA Engineers?
Un equipo necesita un QA Lead cuando tiene tres o más QA Engineers, cuando la estrategia de calidad varía caóticamente entre squads, o cuando la dirección no tiene visibilidad de métricas de calidad agregadas. El QA Lead define el estándar de testing común, elige el stack de herramientas, arma el career ladder de QA, mentorea al equipo y traduce calidad a lenguaje de negocio para la gerencia. Por debajo de tres QA, normalmente basta con un QA Engineer senior que ejerza liderazgo técnico sin carga de gestión. Contratar un QA Lead demasiado pronto sobrecarga el rol con gestión inexistente; contratarlo demasiado tarde deja al equipo sin estrategia común.
¿QA debería reportar a Engineering o a un área independiente?
En equipos modernos con cultura shift-left, QA reporta dentro de Engineering y se integra a los squads, porque la calidad es responsabilidad compartida y no una compuerta separada al final. Un área de QA totalmente independiente, que recibe el producto terminado para aprobarlo o rechazarlo, suele generar fricción, demoras y la mentalidad de que la calidad es problema de otro. La excepción son industrias altamente reguladas (banca, salud, sectores con auditoría externa), donde una función de aseguramiento independiente aporta control formal. La mayoría de las empresas tech producto se beneficia de QA embebido en ingeniería, con un QA Lead que define el estándar transversal.
¿Cuánto gana un QA Engineer o QA Lead senior en el mercado tech 2026?
Los rangos referenciales 2026 para el mercado regional, en renta bruta mensual, ubican a un QA manual entre 1,1 y 1,8 millones de pesos, a un QA automation engineer entre 1,8 y 3 millones, a un SDET fuerte entre 2,8 y 4,2 millones y a un QA Lead entre 3,5 y 5,5 millones según tamaño de equipo y madurez de la organización. Los rangos varían por industria, stack, modalidad (remoto USD eleva el piso) y por la escasez del perfil específico. Son estimaciones de mercado, no ofertas; cada empresa define sus bandas según su compensation philosophy. Para detalle por nivel conviene revisar una guía salarial actualizada.
¿Cómo encuentra IT Workers un QA senior si los buenos no están buscando trabajo?
Los mejores QA Engineers y QA Leads casi nunca están en bolsas de empleo: están trabajando felices en otra empresa y no postulan. IT Workers trabaja con hunting de talento pasivo: identificamos a esos profesionales, les presentamos el proyecto, el equipo y el desafío técnico, y los entusiasmamos a evaluar un cambio que no estaban buscando. El proceso entrega una terna calificada en cuatro días hábiles, con garantía de 90 días y fee solo por éxito. No publicamos avisos esperando que llegue gente; vamos por la persona específica que resuelve el cuello de botella de calidad de la empresa.
¿Listo para sumar el QA Engineer o QA Lead que tu producto necesita?
Conversación estructurada de 20 minutos para diagnosticar tu cuello de botella de calidad y armar la búsqueda correcta. Terna en 4 días hábiles, garantía de 90 días, fee solo por éxito. Recomendación honesta, sin venta forzada.
Solicitar candidatos WhatsApp directo- — Documentación oficial de Playwright, 2024-2025
- — Cypress: end-to-end testing framework, 2024-2025
- — k6: load and performance testing, 2024-2025
- — Martin Fowler: The Practical Test Pyramid, 2018-2024
- — Get on Board, reportes de mercado tech LATAM, 2024-2025
- — DORA: research on software delivery performance, 2024