Belajar System Analyst - Testing Support (UAT)

#Pendahuluan

Setelah di episode 13 kalian memetakan integrasi QRIS, akuntansi, dan supplier, sistem TokoKita kini terbangun dan masuk fase penentu sebelum go-live pilot: testing — khususnya User Acceptance Test. Episode ini membahas peran SA sebagai pendukung testing: dari menyusun test scenario sampai memfasilitasi sign-off.

Mengapa SA tidak bisa berlepas di fase ini? Karena QA menguji apakah sistem bekerja sesuai spesifikasi, tetapi hanya kalian yang tahu apakah spesifikasinya sendiri benar. Saat tester menemukan perilaku aneh, keputusan "ini bug atau begini memang desainnya?" hanya bisa dijawab pemilik requirement. Lebih penting lagi: UAT adalah momen kebenaran analisis kalian — setiap ambiguitas yang lolos dari episode-episode lalu akan muncul sebagai pertanyaan, bug, atau debat di ruang UAT ini.

#Peta Testing & Posisi SA

Testing modern bertingkat, dan tiap tingkat punya pemilik utama:

Fokus episode ini di baris terakhir. Prinsipnya: semakin ke atas piramida, semakin dekat dengan pertanyaan bisnis "apakah ini menyelesaikan masalah?" — dan itu ranah alami analyst.

#Dari Requirement ke Test Scenario

Test scenario yang baik lahir dari requirement yang bernomor (episode 4). Rantai pelacakannya (traceability):

FR-07 / UC-01 / US-12  ->  TC-014 ... TC-021
Setiap requirement minimal punya 1 scenario;
setiap scenario selalu merujuk sumbernya.

Matriks pelacakan sederhana menjawab dua risiko sekaligus: requirement tanpa scenario (tidak akan dites) dan scenario tanpa requirement (uji mubazir atau fitur tak diminta).

Format scenario yang kita pakai di 05-uat/:

ID            : TC-016
Referensi     : UC-02, INT-01, NFR-05
Jenis         : Fungsional - integrasi
Prasyarat     : Shift aktif; produk "Teh Kotak" stok 12;
                koneksi internet normal
Langkah       :
  1. Scan Teh Kotak x1 (total Rp 4.500)
  2. Tekan BAYAR -> pilih QRIS
  3. Scan QR dengan e-wallet, setujui
Hasil diharapkan :
  a. QR tampil maksimal 10 detik
  b. Status berubah "LUNAS" otomatis <= 5 detik
     setelah bayar
  c. Struk tercetak dengan baris QRIS + issuer
  d. Stok Teh Kotak menjadi 11
  e. Callback ganda dikirim simulator -> transaksi
     tetap satu catatan (idempotency)
Status        : [ ] Pass  [ ] Fail  Penguji: ____ Tanggal: ____

Perhatikan langkah (e): scenario integrasi wajib menguji mode gagal yang kita rancang di episode 13 — callback ganda, timeout, fallback tunai. Scenario bahagia-saja adalah pemborosan UAT paling umum.

#Jangan Lupa Non-Fungsional

NFR juga butuh scenario terukur — bukan "terasa cepat":

#Persiapan UAT Pilot

Kegagalan UAT sering soal persiapan, bukan sistem. Checklist TokoKita:

1. Environment pilot — build versi release-candidate di device kasir sungguhan (tablet target), printer fisik, jaringan toko asli.
2. Data uji realistis — master produk hasil migrasi Excel Denpasar (bukan "Produk A/B/C"); stok angka mirip kenyataan agar selisih terasa konteksnya.
3. Penguji nyata — Sinta sang kasir dan Andi staf gudang sebagai aktor utama; manajer QA internal melengkapi. Stakeholder bisu akhirnya di kursi penguji.
4. Jadwal realistis — sesi di jam sepi toko (09.00-11.00), 2-3 hari, dengan opsi lanjutan untuk perbaikan.
5. Briefing singkat — jelaskan tujuan ("kita mencari cacat bersama, bukan uji Anda"), cara mencatat temuan, dan larangan memperbaiki di tempat saat sesi.

#Defect Triage: Severity vs Priority

Temuan UAT dicatat dalam log dengan dua sumbu penilaian yang sering tertukar:

Contoh nyata TokoKita: struk tidak tercetak tapi transaksi tersimpan = severity tinggi, priority sedang (work-around: cetak ulang); total kembalian salah Rp 500 pada diskon = severity tampak kecil, priority kritis — uang salah merusak kepercayaan dan rekonsiliasi.

Alur penanganannya sederhana namun disiplin:

Keputusan triage "bug atau begini memang desainnya" adalah kontribusi khas SA: kalau desainnya yang keliru, update spesifikasi dan komunikasikan ke stakeholder — jangan biarkan dev "memperbaiki" sesuai spec yang ternyata salah.

#Kriteria Kelulusan & Sign-Off

UAT harus punya garis finis yang disepakati sebelum mulai. Exit criteria pilot TokoKita:

• 100% scenario Must (termasuk offline & QRIS) status pass.
• Nol open defect P1; P2 maksimal 2 dengan work-around tertulis dan tanggal rilis.
• Seluruh penguji inti menandatangani lembar hasil.
• Data hasil UAT diarsipkan sebagai baseline regresi rilis berikutnya.

Sign-off bukan formalitas tanda tangan, melainkan serah terima tanggung jawab: sponsor menyatakan sistem siap dipakai produksi, dan keputusan itu berdasarkan bukti log UAT — bukan tekanan jadwal. Dokumen sign-off satu halaman: lingkup yang diuji, ringkasan pass/fail, defect tersisa beserta mitigasinya, nama-tanggal-tanda tangan.

#Kesalahan Umum

1. UAT digelar H-1 go-live — tidak ada waktu memperbaiki temuan, maka semua temuan jadi keputusan sulit: rilis cacat atau mundur jadwal. Beri UAT buffer minimal satu sprint.
2. Penguji salah orang — manajer yang jarang pegang kasir menguji alur kasir. Hasilnya komentar arsitektural, bukan temuan operasional.
3. Scenario tanpa data prasyarat — "stok cukup" tanpa angka membuat hasil tak bisa direproduksi. Prasyarat harus spesifik dan bisa disiapkan ulang.
4. Log temuan di WhatsApp — tersebar, tak terlacak, hilang. Satu spreadsheet/log terpusat, WA hanya untuk notifikasi.
5. Sign-off di bawah tekanan — "sudah ditandatangani Pak Budi jam 9 malam demi jadwal." Sign-off tanpa bukti lengkap adalah bom waktu yang meledak sebagai insiden produksi.

#Penutup

Inti yang harus dibawa pulang:

• SA memastikan rantai requirement-scenario terlacak dua arah; scenario integrasi dan non-fungsional wajib menguji mode gagal yang dirancang.
• UAT sukses ditentukan persiapan: environment nyata, data realistis, penguji pengguna sesungguhnya, dan aturan main yang jelas.
• Triage pisahkan severity dari priority; keputusan "bug vs by-design" adalah wilayah ahli SA — ikuti dengan update spec bila desainnya yang salah.
• Exit criteria disepakati sebelum UAT dimulai; sign-off adalah serah terima tanggung jawab berbasis bukti, bukan formalitas kalender.

Sistem sudah lulus di tangan penggunanya — tantangan berikutnya justru manusiawi: bagaimana membuat seluruh organisasi menerima cara kerja baru. Di episode 15 selanjutnya kita membahas change management & adoption: program training kasir, strategi komunikasi rollout, dan rencana adopsi supaya sistem TokoKita benar-benar dipakai, bukan sekadar terinstall. Pastikan tetap semangat!