Alur yang berlanjut dari registrasi ke verifikasi lalu checkout sering punya CAPTCHA di lebih dari satu titik, dan pengujian end-to-end untuk alur seperti ini gampang rapuh: token dari langkah pertama sudah kedaluwarsa saat pipeline baru sampai di langkah ketiga, atau retry di tengah alur malah memicu solve baru padahal token lama masih sah. Panduan ini merinci pola orkestrasi yang membuat pengujian multi-langkah stabil dan bisa direproduksi di lingkungan QA milik Anda sendiri.
Cakupan panduan ini: khusus lingkungan QA, staging, dan pra-produksi milik sendiri atau yang sudah Anda punya otorisasinya. Isinya adalah pola diagnostik, pengujian, dan observabilitas untuk integrasi CAPTCHA Anda sendiri — bukan untuk situs pihak ketiga atau alur tanpa otorisasi.
Kenapa CAPTCHA multi-langkah gampang bikin pengujian rapuh
Banyak alur produksi bukan cuma satu form dengan satu CAPTCHA. Registrasi bisa punya widget reCAPTCHA di langkah pendaftaran, Cloudflare Turnstile di langkah verifikasi, lalu tantangan lain lagi di checkout. Kalau tes end-to-end memperlakukan tiap langkah sebagai unit terpisah, tim QA biasanya menabrak dua masalah: token yang sudah diselesaikan di langkah awal tidak berlaku lagi begitu proses sampai ke langkah berikutnya, dan retry otomatis pada satu langkah malah memicu solve baru padahal token lama masih sah. Pendekatan yang lebih tahan banting: orkestrasi seluruh alur sebagai satu unit uji, dengan satu identitas kasus yang diikuti dari awal sampai akhir.
Merancang pipeline: kasus_qa dan langkah_id
Setiap eksekusi pengujian mendapat dua identitas: kasus_qa untuk skenario secara keseluruhan (misalnya "registrasi-baru" atau "checkout-kartu-kredit") dan langkah_id untuk posisi di dalam skenario itu. CaptchaAI hanya dipanggil pada langkah yang benar-benar menampilkan widget — kebanyakan alur multi-langkah cuma punya CAPTCHA di satu atau dua titik, jadi pipeline butuh logika kondisional yang mengecek keberadaan widget dulu, bukan memanggil solver di setiap langkah secara membabi buta. Pemisahan dua identitas ini juga yang membuat log dan dashboard bisa dikelompokkan per skenario sekaligus per langkah.
Menjaga idempotensi saat retry di tengah alur
Retry adalah bagian normal dari pipeline CI, tapi retry yang naif di alur multi-langkah gampang memboroskan thread. Aturan praktisnya: retry dengan langkah_id yang sama harus menggunakan kembali token yang masih dalam masa berlaku, bukan meminta solve baru dari nol. Kombinasikan dengan backoff bertahap (mis. 1 detik, 2 detik, 4 detik) untuk error sementara seperti kegagalan jaringan atau ERROR_NO_SLOT_AVAILABLE, lalu hentikan retry begitu error-nya permanen (mis. kesalahan otorisasi) — mengulang error semacam itu cuma membuang waktu eksekusi CI.
Observabilitas: satu id, satu jejak lengkap
Idealnya, satu kasus_qa cukup untuk menelusuri seluruh eksekusi dari awal sampai akhir. Catat log terstruktur per langkah dengan metrik yang sama: durasi total token, kode respons HTTP, task ID CaptchaAI, dan kedalaman antrean saat itu. Pisahkan saluran log per lingkungan (development, staging, pra-produksi), lalu korelasikan lintas langkah dengan distributed tracing (mis. OpenTelemetry) lewat correlation id yang sama dengan kasus_qa. Dashboard yang mengelompokkan waktu per langkah dan hasil backend per kasus uji membuat kegagalan lebih cepat dilacak — memutar ulang skenario penuh dari satu id biasanya memangkas waktu diagnosis insiden setidaknya separuh.
Skenario: menguji alur registrasi-verifikasi-checkout
Bayangkan tim QA di startup e-commerce atau agensi price-monitoring Indonesia yang men-deploy pipeline CI ke region AWS ap-southeast-3 (Jakarta) atau ap-southeast-1 (Singapura). Setiap malam, pipeline menjalankan puluhan skenario kasus_qa, masing-masing melewati tiga langkah dengan CAPTCHA: pendaftaran akun uji, verifikasi email/OTP, dan checkout di keranjang staging. Karena eksekusinya meledak dalam waktu singkat, bukan tersebar sepanjang hari, model biaya thread-based CaptchaAI relevan di sini: satu plan BASIC ($15/bulan, 5 thread) sudah cukup untuk tim QA kecil yang menjalankan beberapa skenario paralel semalam, dan karena solve per thread tidak dibatasi, menjalankan ulang seluruh regression suite tidak menambah biaya. Untuk data pengguna uji, ingat UU Pelindungan Data Pribadi (UU 27/2022) — batasi pengujian pada data yang memang berhak Anda proses, dan hindari data pribadi asli di staging.
Pemecahan masalah cepat
| Gejala | Penyebab | Tindakan |
|---|---|---|
| Tes tidak menemukan widget CAPTCHA | Selector/timing tidak cocok dengan staging | Periksa selector, tunggu widget render sebelum polling |
CaptchaAI membalas ERROR_NO_SLOT_AVAILABLE |
Semua thread di plan sedang terpakai | Retry dengan backoff, atau naikkan alokasi thread |
| Backend QA menolak token | action/sitekey tidak cocok konfigurasi asli |
Bandingkan dengan konfigurasi produksi yang direplikasi ke staging |
| Langkah kedua gagal walau langkah pertama sukses | Token dari langkah sebelumnya sudah kedaluwarsa | Selesaikan token sedekat mungkin dengan waktu pakainya |
Checklist sebelum menjalankan di CI
- Cakupan pengujian dibatasi pada aplikasi sendiri atau sumber daya yang Anda punya otorisasinya.
- API key CaptchaAI disimpan di secret manager CI atau vault, bukan di source code.
- Setiap eksekusi mencatat latensi dan kode status respons per langkah.
- Strategi retry idempoten dengan batas atas untuk error sementara.
- Seluruh skenario
kasus_qadapat direproduksi ulang di pipeline CI dari awal sampai akhir.
Contoh kode: validasi widget di staging
Contoh Python berikut mengirim dan mengambil hasil CAPTCHA saat memvalidasi satu langkah di staging Anda sendiri. Pola submit → simpan task ID → polling ini sama untuk tiap langkah dalam kasus_qa — ganti parameter method dan sitekey sesuai widget yang muncul.
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)
Pertanyaan umum
Apakah pengujian ini menyentuh trafik produksi?
Tidak. Semua contoh mengasumsikan domain QA milik sendiri seperti staging.example.com. Replikasi konfigurasi CAPTCHA produksi — sitekey, action, urutan langkah — ke staging Anda supaya hasilnya representatif.
Apa bedanya kasus_qa dan langkah_id?
kasus_qa mengidentifikasi satu skenario uji secara keseluruhan (misalnya seluruh alur registrasi-verifikasi-checkout), sementara langkah_id menandai posisi spesifik di dalamnya. Kombinasi keduanya membuat log dan dashboard bisa ditelusuri per langkah maupun per skenario penuh.
Bagaimana kalau CAPTCHA cuma muncul sesekali, tidak di setiap eksekusi?
Jangan panggil CaptchaAI secara membabi buta di setiap langkah. Tambahkan pengecekan kondisional yang mendeteksi keberadaan widget (mis. iframe reCAPTCHA atau container Turnstile) sebelum memutuskan perlu solve atau tidak — ini menghemat thread dan membuat log lebih akurat.
Boleh menulis API key CaptchaAI di source code?
Tidak boleh. Suntikkan lewat secret manager CI, environment variable, atau vault. Key yang sudah ter-commit ke repository dianggap bocor dan harus dirotasi segera dari dashboard CaptchaAI.
Strategi apa yang disarankan untuk error sementara seperti ERROR_NO_SLOT_AVAILABLE?
Retry idempoten dengan exponential backoff (mis. 1 detik, 2 detik, 4 detik) dan batas atas jumlah percobaan. Error jaringan, respons 5xx, dan ERROR_NO_SLOT_AVAILABLE layak di-retry; error otorisasi yang persisten tidak boleh di-retry — perbaiki dulu penyebabnya.
Panduan terkait yang aman
- Mulai cepat CaptchaAI dari nol
- QA CAPTCHA terotorisasi
- Menguji endpoint CAPTCHA pada formulir milik sendiri
- Debug saat tes browser gagal padahal panggilan API berhasil
- Cara menyelesaikan reCAPTCHA v2 lewat API
- Cara menyelesaikan Cloudflare Turnstile lewat API
- Cara menyelesaikan GeeTest v3 lewat API
Rangkai dan validasi pengujian CAPTCHA multi-langkah Anda di lingkungan sendiri dengan CaptchaAI.
