Copilot generó 40 pruebas en ocho minutos. 31 compilan. 22 pasan en CI. La coverage de líneas saltó del 41% al 58%. El Change fail rate en producción no se movió. La aserción en la mitad de los archivos es assertNotNull(result). SAST en el mismo pipeline tiene 180 findings, de los cuales doce son CWEs reales. Nadie tiene un ticket para triage.
Este no es un problema del modelo. Es un problema del oráculo. La automatización de pruebas con AI sin una quality gate se parece a la calidad del código. Es un build verde sobre el comportamiento actual, incluyendo el error. El LLM no sabe lo que debería haber sucedido. Sabe lo que hay en el repo.
A continuación, una distinción que falta en los briefs de 'buscamos un tester con AI': cuándo contratar a un SDET (body leasing QA automation), y cuándo la pirámide de pruebas y SAST requieren un squad. Hemos detallado las tarifas por hora por separado: cuánto cuesta el body leasing de IT en 2026. Aquí calculamos por qué la coverage de Copilot es la forma más cara de tener un dashboard tranquilo.
Una frase que no está en la diapositiva de "AI testing"
Una prueba que pasa no demuestra nada. Lo demuestra una prueba que puede fallar. Meta en Instagram y Facebook no subía el output del LLM a main. Subía lo que pasaba el filtro: build, pass estable, aumento medible de la coverage, aprobación del ingeniero. El 25% de las clases generadas aumentó la coverage. El resto cayó en la quality gate. Esto es un producto. No un prompt.
1. Anatomía: prueba verde, oráculo muerto
Una semana típica de calidad en un banco, telco o fintech no se parece a un tutorial de Playwright. Se parece a tres bucles desconectados:
- Unit. Desarrollador, JUnit o pytest, Copilot en el IDE. Artefacto: el archivo
*Test.java, que nadie lee, porque "pasa". - E2E. QA hace clic en staging o en un Selenium grabado. Flaky en CI, así que el job es
allow_failure: true. - “Seguridad”. Sonar / Checkmarx en el pipeline. Quality gate configurado para no bloquear el release. Los findings se acumulan en "won't fix".
Tres síntomas de que tienen un generador, no automatización de pruebas:
- Oráculo clonado del SUT. El test llama al mismo helper que producción y compara el resultado con el resultado. Redondeo de FX, descuento, VAT — el bug está en el helper, el test lo canoniza.
- Coverage de líneas sin mutation score. PIT o Stryker matarían a un mutante en tres segundos. Nadie lo ejecuta. El KPI del equipo es el % de líneas, no el número de mutantes eliminados.
- SAST sin SLO. Un CWE crítico en pagos lleva 120 días pendiente porque "false positive last time". El LLM de pruebas no lo detectará: SAST lee el patrón, el test lee el comportamiento. Son dos alarmas diferentes.
Por eso, el brief "tester que sabe Copilot" sin el contexto del oráculo es la forma más cara de conseguir otro build verde. Las competencias que realmente construyen la automatización de pruebas se encuentran en las landing pages: testers y QA automation, JS/TS (Playwright, Cypress), Java, Python. SAST y Secure SDLC añaden cybersecurity / DevSecOps. CI, donde estos jobs realmente funcionan: DevOps / SRE.
2. Lo que dicen los estudios, no las presentaciones de „AI writes tests”
No necesitan otra definición de shift-left. Necesitan un umbral en el que una prueba generada tenga derecho a entrar en main — y el derecho a no entrar si solo compila.
- 75 / 57 / 25 — y solo después el humano. Alshahwan y col., Automated Unit Test Improvement using Large Language Models at Meta (FSE 2024, arXiv:2402.09171): TestGen-LLM mejora las pruebas existentes escritas por humanos, no escribe la suite desde cero. En Reels y Stories (Instagram), el 75% de las pruebas generadas se construyen, el 57% pasan de forma estable, el 25% aumenta la coverage. En los test-a-thons de Instagram y Facebook, la herramienta mejoró el 11,5% de las clases a las que se aplicó. El 73% de las recomendaciones fueron aceptadas por los ingenieros de Meta para producción. El filtro (compilación, ausencia de flakiness, delta de coverage) sirve para que la alucinación no llegue a main. Los autores lo llaman Assured Offline LLMSE: el output del modelo es un candidato, no código.
- La coverage aumenta cuando el LLM recibe una brecha, no el archivo completo. Pizzorno y Berger, CoverUp: Effective High Coverage Test Generation for Python (arXiv:2403.16218): bucle de coverage → prompt para fragmento no cubierto → prueba → medición. Mediana line+branch 80% versus 47% con CodaMosa; versus MuTAP 89% a 77% en total. Esto no es magia de GPT. Esto es feedback de instrumentación en bucle, análogo a PSI en continuous training.
- ChatGPT puro daña las aserciones. Yuan y col., No More Manual Tests? Evaluating and Improving ChatGPT for Unit Test Generation (arXiv:2305.04207): las pruebas de ChatGPT fallan en la compilación y en aserciones incorrectas. ChatTester (generador + refiner iterativo) produce un 34,3% más de pruebas compilables y un 18,7% más con aserciones correctas. Ni siquiera el „self-repair” del modelo elimina la necesidad de un oráculo humano: el refiner mejora la sintaxis y el assert, no la especificación de negocio.
- Un modelo más reciente no reemplaza la quality gate. Konstantinou, Degiovanni y Papadakis (arXiv:2601.09695, 2026) replican HITS, SymPrompt, TestSpark y CoverUp en LLM más recientes: un prompt ingenuo a veces es mejor en coverage de líneas (+17,7%), ramas (+19,8%) y mutation score (+20,9%) que los pipelines más antiguos. La conclusión operativa es opuesta a la diapositiva „compren Copilot”: un modelo más potente aumenta el volume de candidatos. Un volume sin filtro significa más pruebas verdes para revisar. La revisión es el cuello de botella, no el token.
Conclusión arquitectónica clave
La automatización de pruebas con IA comienza con la quality gate, no con la licencia. El generador escribe un candidato. CI verifica: compilación, ausencia de flakiness, delta de coverage o mutation score, ausencia de clon del oráculo del SUT. SAST por separado: un CWE crítico bloquea el merge. El humano (SDET) acepta lo que el filtro no puede: si la aserción describe el contrato o el bug actual. Si cualquiera de los pasos es „pegar de Copilot y merge”, no tienen calidad de código. Tienen velocidad.
3. Estudio de caso en producción: coverage 71%, bug en FX en producción
Desde la práctica de ingeniería: de Copilot a mutation score
API de pagos, Java 17 + Spring Boot, E2E en Playwright, SAST: SonarQube en GitLab CI. El equipo trabajó de la siguiente manera:
- unit: desarrollador + Copilot, JUnit 5, coverage gate 60% de líneas,
- E2E: QA, rutas happy-path grabadas, job marcado como opcional,
- SAST: quality gate desactivado en la rama de hotfix "para poder cumplir el plazo",
- métrica del sprint: % de coverage. No change fail rate. No el número de mutantes eliminados.
Problema: en el sprint, el coverage del módulo de billing pasó del 44% al 71%. Dos semanas después, en producción, el redondeo de FX (centavos en la conversión de moneda) subestimó el monto. Las pruebas llamaban a FxRounding.round(amount) — el mismo helper que en producción — y comparaban con el resultado del helper. El bug estaba en el helper. La suite lo validaba. Sonar había marcado lógica duplicada durante cuatro meses. Ticket: won’t fix.
Cambio: un quality gate como el de Meta, pero en el stack de Spring. Un nuevo test con LLM entra cuando: (1) compila, (2) pasa tres veces seguidas, (3) PIT muestra una delta positiva de mutation score en la clase, (4) la aserción no llama al SUT como oráculo — el expected es una constante, una tabla de casos o un oracle separado en testdata, (5) el SDET revisa el PR. SAST: CWE en el paquete payments bloquea el merge, no abre Slack.
Medición: el coverage disminuyó en papel (se eliminaron pruebas tautológicas). El mutation score en billing aumentó. Otro hotfix de FX fue detectado en CI, no en el cliente. Tiempo de revisión de PR con pruebas: minutos, no "aceptamos porque está en verde". Esto no es Copilot Enterprise. Es el propietario del oráculo.
Los números del paper de Meta no se trasladan 1:1 a su billing. Lo que se traslada es la mecánica: 75% "se construye" aún no es calidad. 25% con delta de coverage y 73% de aceptación ya es un proceso que puede ser auditado por la comisión de riesgos — análogamente al quality gate PSI en los servicios de MLOps.
4. Tabla de decisión: qué prueba, qué composición
| Enfoque | Complejidad | Señal de calidad | Costo de CI / tokens | Sobrecarga para el equipo | Cuándo aplicar |
|---|---|---|---|---|---|
| Manual / exploración | Baja | Alto en UX y casos límite, cero en regresión | Bajo | Alto con cada lanzamiento | Nueva superficie, falta de contrato API, PoC |
| E2E grabado (Selenium IDE, codegen) | Baja | Happy-path; flaky con CSS | Medio (minutos por job) | Medio (reparación de selectores) | Demo, no pirámide; no como única puerta |
| SDET + pirámide (unit, API, Playwright estrecho) | Media | Regresión, contrato, p95 del job | Medio | Medio, disminuye cuando la suite es estable | Producto con CI, equipo estable, SLA para el lanzamiento |
| LLM dump (Copilot → commit, gate = coverage) | Baja | Falso: las líneas crecen, los mutantes viven | Bajo–medio (tokens) | Oculto (deuda de revisión y producción) | Nunca como puerta de merge. Ejercicio, no proceso |
| Assured LLMSE (filtro Meta: build, pass, delta, akcept) | Alta | Delta de cobertura / mutation score + revisión | Medio–alto (bucle + tokens) | Alto al inicio, disminuye cuando el filtro es estable | Monolito grande, suite existente, SDET en la puerta |
| SAST con SLO (CWE en critical path bloquea) | Media | Patrón en el código, no comportamiento | Bajo–medio | Triage; sin propietario = cero | Pagos, IAM, datos personales; junto a las pruebas, no en su lugar |
QA automation / SDET no es un "desarrollador más barato" y no es un pentest. Rangos 2026: especialista 110–160 PLN/h, cliente 160–240 PLN/h, 26–38 mil B2B. El tester manual se sitúa significativamente más bajo. Pentest y GRC se encuentran en otro landing. Margen 10–25%. Mapa, no lista de precios — detalles en las tarifas de 2026.
5. Anti-patrones que no están en el tutorial de Copilot
- Coverage como KPI del generador. El equipo celebra el 71% de las líneas. PIT dejaría el 40% de los mutantes vivos. Meta publica el 25% de las clases con delta de coverage no porque el modelo sea débil. Sino porque el filtro descarta el resto. Su dashboard sin este filtro miente en la dirección opuesta.
- Expected calculado con el mismo código que producción. Un clásico en facturación, impuestos, FX, asignación de descuentos. La prueba «documenta» el bug. El oráculo es una tabla de casos, una constante de contabilidad o un oracle separado y revisado. No
service.calc(x)versusservice.calc(x). - SAST en modo informativo para siempre. 180 findings, cero owner, quality gate desactivado para un hotfix. LLM de pruebas no reemplazará a SAST: no leerá CWE-89 en string concatenation si la aserción verifica HTTP 200. A la inversa: SAST no detectará un redondeo incorrecto de un céntimo. Dos alarmas. Dos propietarios o un SDET con DoD para ambos.
- Brief «QA con AI» para el rol de SDET. Obtendrán a alguien que hace clic y pega. No obtendrán a una persona que rechace el 75% del output del modelo. El mercado se rompió de la misma manera que con MLOps: el tester clásico tiene oferta, el SDET con oráculo y CI no. Un anuncio con una etiqueta incorrecta recoge CV en 48 h y cero competencias de mutation score.
- Falso equipo de calidad. Manual de un vendor A, «alguien de Cypress» de un B, SAST «al 10% de security». Tres onboardings, cero Definition of Done común para el merge. La anatomía de este error la detallamos en team leasing vs body leasing 2026. Esto no es staff augmentation. Es un impuesto de integración.
6. Playbook: a quién contratar y en qué orden
No empiecen por la licencia de Copilot Enterprise. Empiecen por la pregunta de qué bucle está bloqueando el release: unit, E2E, SAST o la falta de un propietario del oráculo.
- Una brecha en la pirámide existente. Tienen JUnit/pytest, Playwright en la ruta crítica, CI, alguien que revisa los PR. Falta un propietario del filtro LLM y el triage SAST. Es el clásico body leasing de testers y SDET: una persona, su stand-up, su DoD. Primeros perfiles en días, no en un trimestre — hacemos sourcing bajo demanda, no vendemos un banco nominal para mañana por la mañana.
- La única prueba es un clic. No hay unit, no hay contrato API, Sonar lleva medio año parado. Una sola persona no lo coserá. Equipo de 3–5: SDET (pirámide, CI), QA exploratorio (lo que el generador no inventará), DevOps si los jobs no existen. Esto está más cerca del team leasing que de 'compraremos Copilot y un junior'.
- Los datos de prueba no salen de la VPC. Fixtures de pagos, PESEL, NDA. Contratista en su IAM, su entorno, contrato T&M con NDA, encargo y IP por parte del cliente. Un volcado de producción en Colab 'para que Copilot adivine mejor las pruebas' es una fuga. Un prompt con código bajo NDA a la nube de un modelo público — también.
- Ramp-up. Persona para un equipo existente: primeros CV en 24–48 h, inicio después de sus entrevistas y contrato. Squad desde cero: semanas, no un sprint, porque están cosiendo permisos, datos de prueba y DoD para el merge. La mentira de 'tres SDET seniors desde el lunes' es un CV o un banco que no tenemos — y no vamos a fingir.
Commoditech desde 2012 realiza T&M y reclutamiento permanente desde Varsovia. Más de 80 especialistas en la red, no un idle bench. Un brief de T&M o success fee se puede presentar desde el IDE a través de MCP para agentes de IA, no solo desde el formulario. Las cantidades para un stack específico las calcula una persona; los rangos están en el artículo sobre tarifas, no en el JSON del agente.
FAQ
¿Reemplazará LLM la automatización de pruebas y a los testers QA?
No. LLM es un generador de candidatos. Meta TestGen-LLM: el 75% de las pruebas se construyen, el 57% pasa de forma estable, el 25% aumenta el coverage. El 73% de las recomendaciones llegaron a producción, porque el filtro (compilación, pass, delta de coverage) y la revisión del ingeniero descartaron el resto. Sin una quality gate, compráis aserciones verdes sobre el comportamiento actual, incluyendo el error. ChatTester demuestra que incluso el self-repair del modelo corrige la sintaxis, no la especificación.
¿Cuándo contratar un SDET y cuándo un equipo de QA?
Una persona, cuando la pirámide está en pie (unit + API + E2E estrecho en CI), y falta un propietario de la quality gate: mutation score, triage SAST, revisión de pruebas de Copilot. Un equipo de 3-5 (SDET + QA exploratorio + alguien de CI), cuando la única prueba es un clic en staging, y Sonar lleva medio año con 200 findings en "won't fix". Un SDET por sí solo no escribirá la lógica de negocio por el product owner. Un tester manual por sí solo no mantendrá un job en GitLab. Si no tenéis a quién revisar un PR de un contractor, no compréis body leasing. Comprad un lead más un rol o un squad.
¿Cuánto cuesta el body leasing de SDET / QA automation en Polonia en 2026?
QA automation / SDET: especialista 110–160 PLN/h, cliente 160–240 PLN/h, 26–38 mil. B2B. Un tester manual es significativamente más barato; un SDET no. Pentest y NIS2 son otra tarifa y otro landing. El margen del proveedor es del 10–25% — si alguien promete un 8% con un reemplazo en 5 días, añádanlo en otra línea. Este es un mapa del mercado, no una oferta. La cantidad para un brief la calcula una persona. Detalles en tarifas 2026.
¿En qué se diferencia SAST de las pruebas generadas por LLM?
SAST lee el código sin ejecutarlo y busca patrones (SQLi, XSS, secretos, CWE). LLM escribe una prueba que debe fallar ante un comportamiento incorrecto. SAST sin propietario es un dashboard de false positive. LLM sin filtro es coverage vanity. Ambos necesitan SLO: un CWE crítico no puede permanecer en "informational", una prueba de Copilot no puede entrar sin una delta de mutation score. No son sustitutos. Son dos jobs en un mismo DoD para el merge.
Fuentes
- Alshahwan, N., Chheda, J., Finogenova, A., Gokkaya, B., Harman, M., Harper, I., Marginean, A., Sengupta, S., Wang, E. (2024). Automated Unit Test Improvement using Large Language Models at Meta. FSE 2024. arXiv:2402.09171. arxiv.org/abs/2402.09171
- Pizzorno, J. A., Berger, E. D. (2024). CoverUp: Effective High Coverage Test Generation for Python. arXiv:2403.16218. arxiv.org/abs/2403.16218
- Yuan, Z., Lou, Y., Liu, M., Ding, S., Wang, K., Chen, Y., Peng, X. (2023/2024). No More Manual Tests? Evaluating and Improving ChatGPT for Unit Test Generation. arXiv:2305.04207. arxiv.org/abs/2305.04207
- Konstantinou, M., Degiovanni, R., Papadakis, M. (2026). How well LLM-based test generation techniques perform with newer LLM versions? arXiv:2601.09695. arxiv.org/abs/2601.09695
- DORA / Google Cloud (2024). Accelerate State of DevOps Report.
- Commoditech — tarifas de body leasing 2026, team leasing vs body leasing, alquiler de testers y SDET.