Use Cases

Pengujian QA situs ritel milik sendiri dengan CAPTCHA

Batasan lingkup: Panduan ini hanya berlaku untuk lingkungan QA, staging, dan praproduksi yang Anda miliki atau Anda pegang otorisasinya. Isinya adalah pola diagnostik, pengujian, dan observabilitas untuk integrasi CAPTCHA Anda sendiri — bukan untuk situs pihak ketiga atau alur tanpa izin.

Begitu tim keamanan memasang CAPTCHA di halaman checkout, suite end-to-end Anda berhenti persis di titik yang sama seperti bot: widget muncul, skrip menunggu, tes merah. Jalan keluar yang tetap jujur secara pengujian adalah membiarkan CAPTCHA aktif di staging, lalu menyelesaikannya lewat API CaptchaAI dari dalam pipeline QA dengan katalog SKU fiktif — sehingga tidak ada satu pun data produksi yang tersentuh.

Mengapa mematikan CAPTCHA di staging justru merugikan

Cara pintas yang paling sering dipakai adalah feature flag yang mematikan widget di lingkungan non-produksi. Konsekuensinya: jalur yang Anda uji bukan jalur yang Anda rilis. Sitekey yang tertukar, domain staging yang belum terdaftar di konsol, callback yang tidak pernah terpanggil, atau token yang kedaluwarsa sebelum form terkirim — semua kelas kesalahan ini baru muncul di produksi, biasanya saat trafik kampanye diskon sedang puncak.

Menjalankan tantangan yang sama di staging menjaga paritas konfigurasi. CaptchaAI menyelesaikan reCAPTCHA v2 dan v3 (termasuk varian Enterprise), Cloudflare Turnstile, Cloudflare Challenge, GeeTest v3, serta CAPTCHA gambar/OCR dan grid; CaptchaFox (beta), Friendly Captcha (beta), dan Lemin (beta) tersedia dalam status beta. hCaptcha dan FunCaptcha (Arkose Labs) belum didukung, dan GeeTest v4 masih berstatus segera hadir — jika checkout Anda memakai salah satunya, pilih tipe widget lain untuk lingkungan uji.

Menyiapkan katalog SKU fiktif di staging

Katalog sintetis adalah pemisah antara pengujian dan insiden data. Sebelum tes pertama dijalankan, siapkan:

  • SKU bertanda jelas (SKU-QA-0001 sampai SKU-QA-0050) dengan harga dan stok tiruan, sehingga hasil tes tidak pernah tertukar dengan produk nyata.
  • Akun pembeli uji khusus staging, tanpa satu pun data pelanggan asli. UU Pelindungan Data Pribadi (UU 27/2022) membuat penyalinan basis data pelanggan ke staging menjadi risiko nyata, bukan sekadar praktik buruk.
  • Gateway pembayaran dalam mode sandbox, sehingga checkout berakhir pada ID pesanan tiruan.
  • Sitekey khusus staging yang terdaftar untuk domain uji Anda, terpisah dari sitekey produksi.

Alur empat langkah yang dijalankan tes Anda

Urutan integrasinya sama untuk semua tipe yang didukung: kirim → simpan task ID → polling → pakai token.

  1. Kirim parameter widget dari halaman staging ke in.php: method sesuai tipe, sitekey uji, dan URL halaman.
  2. Simpan task ID yang dikembalikan. ID ini sekaligus menjadi correlation id di log tes.
  3. Polling res.php setiap 5 detik sampai respons berhenti mengembalikan CAPCHA_NOT_READY. CAPTCHA gambar/OCR selesai di bawah 0.5 detik dan reCAPTCHA v2 di bawah 60 detik — setel batas waktu tes di sekitar 90 detik agar variasi antrean tidak terbaca sebagai kegagalan fitur.
  4. Pakai token pada field form yang sesuai, lalu kirim checkout seperti pengguna biasa.

Contoh pemanggilan QA dari pipeline Python

Contoh berikut adalah alur minimum untuk memvalidasi widget di staging Anda sendiri. Semua nilai sensitif dibaca dari environment variable, jadi skrip yang sama berjalan di laptop maupun runner CI.

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)

Memastikan backend QA benar-benar memverifikasi token

Tes yang hanya memeriksa "halaman berikutnya terbuka" belum membuktikan apa pun. Tambahkan tiga assertion di sisi backend uji Anda:

  • Checkout dengan token valid mengembalikan ID pesanan tiruan untuk SKU fiktif.
  • Checkout tanpa token ditolak dengan kode 4xx, bukan diteruskan diam-diam.
  • Token yang sudah dipakai atau sudah lewat masa berlaku ditolak, dan penolakannya tercatat di log.

Biaya menjalankan CAPTCHA di CI: thread, bukan per penyelesaian

Ini pertimbangan nyata untuk agensi price monitoring dan tim data startup e-commerce yang menagih klien per proyek. CaptchaAI ditagih per thread yang berjalan bersamaan, bukan per CAPTCHA, dan setiap paket mencakup penyelesaian tanpa batas per thread selama bulan berjalan.

Contoh dari pola regresi malam hari: 40 skenario checkout dengan paralelisme 5 sudah tercakup paket BASIC ($15/bulan, 5 thread), sedangkan matriks CI dengan 15 job serentak pas dengan STANDARD ($30/bulan, 15 thread). Tagihan tetap sama entah suite dijalankan sekali atau sepuluh kali semalam, sehingga estimasi biaya QA mudah dipertanggungjawabkan ke klien.

Observabilitas eksekusi QA

Catat log terstruktur untuk setiap eksekusi: durasi sampai token diterima, kode respons HTTP, task ID, dan kedalaman antrean tes. Pisahkan saluran log per lingkungan (development, staging, praproduksi) dan korelasikan dengan distributed tracing — misalnya OpenTelemetry — lewat correlation id yang sama.

Perhatikan juga lokasi runner. Tim di Indonesia biasanya menjalankan CI di AWS ap-southeast-1 (Singapura) atau ap-southeast-3 (Jakarta), dan selisih latensi antar-region cukup untuk mengubah bentuk grafik durasi tes. Simpan garis dasar per region sebelum menuduh solver sebagai penyebab tes yang melambat.

Gejala umum dan tindakan yang disarankan

Gejala Tindakan yang disarankan
Tes tidak menemukan widget Periksa selector dan timing render pada halaman staging
CaptchaAI mengembalikan ERROR_NO_SLOT_AVAILABLE Coba ulang dengan exponential backoff; seluruh thread paket sedang terpakai
Backend QA menolak token Bandingkan action dan sitekey tes dengan konfigurasi sebenarnya
Tes hijau di laptop, merah di CI Bandingkan region runner, batas waktu, dan variabel rahasia yang tersedia di job
Durasi tes melonjak tanpa perubahan kode Cek kedalaman antrean dan jumlah thread yang tersedia pada paket Anda

Checklist sebelum suite QA ditandai siap

  • Cakupan pengujian dibatasi pada aplikasi sendiri atau sumber daya yang Anda pegang otorisasinya.
  • API key CaptchaAI berada di secret manager CI atau vault, tidak pernah di source code.
  • Setiap eksekusi mencatat latensi, kode status, dan task ID.
  • Strategi coba ulang bersifat idempoten dan punya batas atas percobaan.
  • Katalog fiktif terpisah penuh dari data produksi, termasuk di basis data laporan.
  • Seluruh suite dapat direproduksi di pipeline CI tanpa langkah manual.

FAQ

Bagaimana jika checkout staging kami memakai hCaptcha?

Belum. hCaptcha tidak didukung saat ini, begitu pula FunCaptcha (Arkose Labs), sementara GeeTest v4 baru berstatus segera hadir. Untuk lingkungan uji, gunakan tipe widget yang didukung seperti reCAPTCHA v2, Turnstile, atau CAPTCHA gambar.

Paket mana yang cukup untuk pipeline QA harian?

Ukurannya adalah jumlah tes yang berjalan bersamaan, bukan jumlah CAPTCHA per bulan. Paralelisme 5 cocok dengan BASIC ($15/bulan, 5 thread); matriks CI dengan 15 job serentak cocok dengan STANDARD ($30/bulan, 15 thread). Penyelesaian per thread tidak dibatasi.

Berapa lama satu tantangan biasanya selesai di dalam tes?

Tergantung tipe: CAPTCHA gambar/OCR di bawah 0.5 detik, reCAPTCHA v2 di bawah 60 detik. Setel batas waktu tes lebih longgar dari angka itu agar antrean tidak terbaca sebagai kegagalan palsu.

Bagaimana menjaga API key tetap aman di runner CI?

Suntikkan lewat secret manager CI, environment variable, atau vault, dan jangan pernah menuliskannya di repository. Key yang pernah ter-commit harus dirotasi, bukan sekadar dihapus dari file terakhir.

Perlukah sitekey produksi dipakai ulang di staging?

Tidak. Daftarkan sitekey terpisah untuk domain staging. Sitekey produksi pada domain uji menghasilkan token yang ditolak backend, dan kegagalan itu mudah salah dibaca sebagai masalah solver.

Panduan terkait yang aman

Uji integrasi CAPTCHA di lingkungan Anda sendiri dengan CaptchaAI.

Komentar dinonaktifkan untuk artikel ini.