Casos de Uso

Reducir interrupciones por CAPTCHA en pruebas QA propias

Alcance seguro: esta guía se aplica solo a tus entornos autorizados de QA, staging y preproducción. Describe diagnóstico y observabilidad de tu propia integración de CAPTCHA — no de sitios de terceros.

Cuando una suite de QA falla de forma intermitente, casi nunca es culpa del CAPTCHA sino del diseño del test. Se corrige en tres frentes: estandarizar el navegador, agrupar los pasos para que un solo token cubra el caso y reutilizar ese token dentro de su TTL. Lo que sobreviva lo resuelve la API de CaptchaAI en segundos.

Por qué tu propio formulario muestra tantos desafíos

Antes de tocar código, mira qué dispara el widget. Las causas se repiten:

  • Cada caso arranca con un perfil de navegador limpio, sin historial de cookies.
  • El runner de CI usa viewport, idioma y user-agent distintos a los de la máquina de quien escribió el test.
  • Un mismo caso pasa tres veces por el formulario y pide tres tokens donde bastaba uno.

Ninguna es culpa de tu proveedor: son decisiones de diseño que puedes cambiar hoy.

Estandariza el navegador en local, staging y CI

Usa la misma configuración de navegador en todos tus entornos. Es la corrección que más ruido elimina, porque acaba con el clásico "en mi máquina funciona":

from selenium import webdriver

def make_driver(headless: bool = True) -> webdriver.Chrome:
    options = webdriver.ChromeOptions()
    if headless:
        options.add_argument('--headless=new')
    options.add_argument('--window-size=1280,800')
    options.add_argument('--lang=es-ES')
    return webdriver.Chrome(options=options)

Guárdala en un módulo compartido: si cada test construye su propio driver, la deriva vuelve en semanas.

Diseña el flujo para que un token cubra el caso completo

Agrupa los pasos

Un caso que valida alta, edición y baja no necesita tres verificaciones: agrupa los pasos en una sesión y coloca el CAPTCHA una sola vez, al principio.

Reutiliza el token dentro del TTL

El token de reCAPTCHA v2 vive poco, del orden de un par de minutos. Mientras siga vigente, reutilízalo en los reintentos del mismo caso_qa. Reutilizar dentro del TTL oficial es higiene de test; acumular tokens por adelantado no lo es.

Mantén viva la sesión de staging

Una sesión HTTP con historial coherente genera menos desafíos que diez sesiones nuevas contra staging.example.com.

Cómo encaja CaptchaAI en tu pipeline propio

El patrón es el mismo sin importar el lenguaje o el framework de pruebas:

  1. Tu test detecta el widget en tu propia aplicación (formulario de QA, landing de staging, endpoint de preproducción).
  2. Envía a CaptchaAI los datos públicos del widget (sitekey, URL, tipo de CAPTCHA).
  3. CaptchaAI devuelve un token válido para esa página.
  4. El test inyecta el token en su campo y envía el formulario.
  5. Tu backend lo verifica con el proveedor, igual que con una persona real.

Este patrón vale solo para integraciones que tú controlas.

Escenario: una agencia que valida un portal de trámites

Un equipo pequeño en Ciudad de México o Madrid mantiene el portal de trámites de un cliente, protegido con reCAPTCHA v2, del tipo que se usa para pedir cita o subir documentación. Su suite nocturna sobre staging tiene 120 casos y pedía unos 300 tokens por ejecución.

Al fijar un único paso con CAPTCHA por caso y reutilizar el token en los reintentos, la cifra cae al orden de un token por caso. reCAPTCHA v2 suele resolverse en menos de 60 segundos y, con el plan BASIC ($15/mes, 5 threads), la ventana nocturna deja de ser el cuello de botella.

En cualquier portal, respeta los términos de servicio y la normativa aplicable de protección de datos (GDPR y LOPDGDD en España, LFPDPPP en México).

Métricas que conviene instrumentar

  • Tokens por caso de prueba — confirma si el rediseño del flujo funcionó.
  • Tiempo de resolución por intento — desde la solicitud hasta la entrega del token.
  • Distribución de errores — por código (ERROR_*, tiempos de espera, fallos de red).

Conserva trazas (logs, capturas, HAR): sin ellas, un fallo intermitente es irreproducible.

Solución de problemas

Síntoma Acción recomendada
El test no detecta el widget Revisa selectores y tiempos en staging
CaptchaAI devuelve ERROR_NO_SLOT_AVAILABLE Reintenta con backoff exponencial
El backend rechaza el token Compara action y sitekey con tu configuración real
Pasa en local y falla en CI Iguala viewport, idioma y user-agent
Tiempos de resolución variables Revisa la concurrencia y los threads de tu plan

Buenas prácticas en tu entorno QA

  • Mantén una clave API de QA separada de la de producción para no mezclar métricas.
  • Versiona la configuración (sitekey, action, umbrales) junto al código de los tests.

Preguntas frecuentes

¿Cuánto tiempo puedo reutilizar un token antes de pedir otro?

Solo dentro del TTL que define el proveedor; en reCAPTCHA v2, del orden de un par de minutos. Después el backend lo rechazará: trata la caducidad como un error esperado.

¿Qué plan necesito para una suite de CI nocturna?

Depende de cuántos casos corran en paralelo, no de cuántos CAPTCHA resuelvas: CaptchaAI cobra por thread concurrente, con resoluciones ilimitadas por thread. BASIC ($15/mes, 5 threads) cubre cinco resoluciones simultáneas; si lanzas 20 workers a la vez, necesitas más threads.

¿Por qué el mismo test pasa en local y falla en CI?

Casi siempre por diferencias de entorno: viewport, idioma, versión de Chrome o ausencia de cookies previas. Iguala la configuración antes de buscar causas más exóticas.

¿Con qué tipos de CAPTCHA funciona esto?

Con los que CaptchaAI admite hoy: reCAPTCHA v2 y v3 (incluida Enterprise), Cloudflare Turnstile y Challenge, GeeTest v3 e imagen/OCR. CaptchaFox, Friendly Captcha y Lemin están en beta. hCaptcha y FunCaptcha no son compatibles; GeeTest v4 figura como próximamente.

Guías relacionadas seguras

Valida tus integraciones de CAPTCHA en entornos propios con CaptchaAI.

Los comentarios están deshabilitados para este artículo.