Mengurangi interupsi CAPTCHA pada pengujian QA milik sendiri

Lingkup aman: Panduan ini berlaku hanya untuk lingkungan QA, staging, dan praproduksi milik sendiri atau yang Anda miliki otorisasinya. Materi membahas pola diagnostik, pengujian, dan observabilitas untuk integrasi CAPTCHA Anda sendiri — bukan untuk situs pihak ketiga atau alur tanpa otorisasi.

Cara paling murah mengurangi interupsi CAPTCHA di suite QA bukan menambah worker, melainkan menekan jumlah tantangan per eksekusi: token dipakai ulang selama masih dalam masa berlaku, langkah tes dikelompokkan agar tidak memicu widget berulang kali, dan sesi staging dipertahankan antar-kasus uji. Hitungannya sederhana. Bila satu run regression memicu 40 tantangan dan tiap penyelesaian memakan belasan detik, itu sekitar sepuluh menit wall-clock yang murni antre — pada pipeline yang jalan puluhan kali sehari, angka itu langsung terasa di durasi build maupun alokasi thread. Turunkan ke delapan tantangan per run, dan Anda dapat dua hal sekaligus: build lebih cepat dan headroom thread yang jauh lebih longgar.

Kenapa jumlah tantangan, bukan kecepatan solve, yang jadi tuas utama

Waktu penyelesaian per tantangan sebagian besar di luar kendali Anda — itu properti tipe CAPTCHA-nya. Yang sepenuhnya ada di tangan Anda adalah berapa kali alur tes menyentuh widget. Skrip yang membuka ulang halaman login pada setiap assertion akan meminta tantangan baru pada setiap assertion, dan biaya itu berlipat seiring bertambahnya kasus uji.

Karena CaptchaAI menagih per thread bersamaan, bukan per penyelesaian, memangkas jumlah tantangan tidak menurunkan tagihan bulanan — tapi memperbesar throughput dari thread yang sudah dibayar. Paket BASIC ($15/bulan, 5 thread) yang tadinya mentok di satu pipeline paralel bisa menopang beberapa pipeline sekaligus. Untuk nightly regression besar, ADVANCE ($90/bulan, 50 thread) memberi ruang antre jauh lebih lega. Cek halaman pricing CaptchaAI untuk alokasi thread terbaru sebelum menentukan paralelisme pipeline.

Desain alur: kelompokkan langkah agar satu token menuntaskan satu kasus

Titik awal yang benar adalah membaca ulang skenario tes, bukan menyentuh kode integrasi. Gabungkan langkah yang berada di balik gerbang yang sama menjadi satu kasus uji, sehingga satu token cukup untuk menuntaskan seluruh assertion di belakangnya. Pola yang biasanya langsung memangkas jumlah tantangan:

1. Pisahkan setup dari assertion. Lakukan login ber-CAPTCHA sekali di fase setup, lalu jalankan seluruh assertion di atas sesi yang sama.
2. Hindari membuka ulang halaman ber-widget hanya untuk mereset state; reset state lewat API internal QA Anda kalau memang tersedia.
3. Jalankan kasus uji yang tidak butuh autentikasi di jalur terpisah agar tidak ikut antre di belakang gerbang CAPTCHA.
4. Untuk data-driven test, iterasikan data di dalam satu sesi, bukan dengan mengulang seluruh alur login per baris data.

Reuse token selama masa berlaku resmi

Coba ulang adalah penyebab tantangan berlebih yang paling sering terlewat. Ketika kasus uji gagal karena batas waktu jaringan atau selector rapuh, banyak framework mengulang kasus itu dari nol — termasuk penyelesaian CAPTCHA yang baru saja berhasil.

Simpan token hasil solve beserta timestamp-nya, lalu pakai ulang pada percobaan berikutnya untuk kasus uji yang sama selama masih dalam masa berlaku resminya. Setelah lewat, minta yang baru. Perlakukan token seperti kredensial berumur pendek: tidak dibagi lintas skenario, dan tidak pernah ditulis ke log.

Sesi persisten di staging

Mempertahankan sesi pengujian mengurangi tantangan yang sebetulnya tidak perlu. Simpan cookie jar per suite, bukan per kasus uji, dan pastikan fixture teardown tidak menghapusnya di antara kasus yang berbagi sesi.

Untuk tim yang men-deploy staging di ap-southeast-1 (Singapura) atau ap-southeast-3 (Jakarta), latensi antara CI runner dan aplikasi staging ikut menentukan seberapa sering batas waktu tes berubah menjadi coba ulang — dan setiap coba ulang berpotensi jadi tantangan tambahan. Menempatkan runner di region yang sama dengan aplikasi staging biasanya lebih efektif daripada sekadar menaikkan nilai timeout.

Contoh pemanggilan QA

Contoh Python berikut menunjukkan alur minimum untuk memvalidasi widget CAPTCHA di staging milik Anda sendiri: kirim task ke in.php, simpan task ID, polling res.php, lalu pakai token yang dikembalikan.

import os
import time
import requests

API_KEY = os.environ['CAPTCHAAI_KEY']
QA_PAGE_URL = os.environ['QA_PAGE_URL']  # contoh: https://staging.example.com/qa-login
QA_SITE_KEY = os.environ['QA_SITE_KEY']


def submit_qa_recaptcha() -> str:
    payload = {
        'key': API_KEY,
        'method': 'userrecaptcha',
        'googlekey': QA_SITE_KEY,
        'pageurl': QA_PAGE_URL,
        'json': 1,
    }
    response = requests.post(
        'https://ocr.captchaai.com/in.php',
        data=payload,
        timeout=30,
    )
    response.raise_for_status()
    return response.json()['request']


def fetch_qa_result(task_id: str) -> dict:
    params = {
        'key': API_KEY,
        'action': 'get',
        'id': task_id,
        'json': 1,
    }
    while True:
        response = requests.get(
            'https://ocr.captchaai.com/res.php',
            params=params,
            timeout=30,
        )
        response.raise_for_status()
        data = response.json()
        if data.get('request') != 'CAPCHA_NOT_READY':
            return data
        time.sleep(5)

Untuk implementasi per tipe, lihat cara menyelesaikan reCAPTCHA v2 lewat API, penanganan Cloudflare Turnstile, dan alur GeeTest v3.

Observabilitas: ukur dulu, optimalkan kemudian

Tanpa angka, semua pekerjaan di atas hanya tebakan. Catat log terstruktur setiap eksekusi QA dengan metrik minimum: jumlah tantangan per run, durasi total token, kode respons HTTP, ID tugas, dan kedalaman antrean.

Pisahkan saluran log per lingkungan (development, staging, praproduksi) dan korelasikan dengan distributed tracing (mis. OpenTelemetry) lewat correlation id. Memutar ulang satu skenario dari satu id memangkas waktu diagnosis — dan, yang lebih penting di sini, membuat perbandingan jumlah tantangan sebelum dan sesudah perubahan alur jadi terukur, bukan sekadar terasa.

Pemecahan masalah

Checklist sebelum merge

• Cakupan pengujian dibatasi pada aplikasi sendiri atau sumber daya yang Anda miliki otorisasinya.
• Kunci CaptchaAI disimpan di secret manager CI atau vault, bukan di source code.
• Setiap eksekusi mencatat latensi, kode status respons, dan jumlah tantangan.
• Strategi coba ulang idempoten dengan batas atas untuk error sementara.
• Token tidak pernah muncul di log build atau artefak CI.
• Pengujian dapat direproduksi di pipeline CI.

Catatan kepatuhan untuk tim di Indonesia: jalankan seluruh pola ini dengan data dummy. UU Pelindungan Data Pribadi (UU 27/2022) membuat pemakaian data pengguna nyata di staging jadi risiko yang tidak sebanding dengan kemudahannya.

FAQ

Berapa banyak tantangan CAPTCHA yang wajar dalam satu run regression?

Tidak ada angka baku — yang penting trennya turun setelah alur dirapikan. Ambil baseline dari beberapa run berturut-turut, lalu perlakukan lonjakan mendadak sebagai sinyal ada fixture atau sesi yang berubah perilakunya.

Apakah memangkas jumlah tantangan menurunkan biaya CaptchaAI?

Tidak secara langsung. Penagihan berbasis thread bersamaan dengan penyelesaian tanpa batas per thread, bukan per penyelesaian. Yang Anda dapat: throughput lebih tinggi dari paket yang sama dan waktu build lebih pendek.

Berapa lama token hasil solve boleh dipakai ulang?

Hanya selama masa berlaku resminya, dan hanya untuk kasus uji yang sama. Lewat dari itu backend QA Anda akan menolaknya, dan memaksakan reuse justru menambah kegagalan tes yang membingungkan.

Bagaimana kalau staging saya memakai tipe CAPTCHA yang tidak didukung, seperti hCaptcha?

hCaptcha dan FunCaptcha (Arkose Labs) memang tidak ada di daftar tipe yang ditangani CaptchaAI, dan GeeTest v4 baru berstatus segera hadir. Siapkan jalur pengujian terpisah untuk halaman tersebut, dan jangan hitung ke dalam baseline jumlah tantangan Anda.

Bagaimana kalau tes membutuhkan beberapa akun QA sekaligus?

Beri tiap akun sesi terpisah dan jalankan paralel sesuai jumlah thread di paket Anda. Menaikkan paralelisme melebihi alokasi thread hanya memindahkan antrean, tidak menghilangkannya.

Panduan terkait yang aman

• Mulai cepat CaptchaAI dalam beberapa menit
• Menjalankan QA CAPTCHA yang terotorisasi
• Menguji endpoint CAPTCHA pada formulir milik sendiri
• Saat tes browser gagal padahal API berfungsi
• Menyelesaikan reCAPTCHA v2 lewat API
• Menangani Cloudflare Turnstile lewat API
• Alur penyelesaian GeeTest v3

Validasi integrasi CAPTCHA Anda di lingkungan sendiri dengan CaptchaAI.