Belajar Game Developer - Game Testing & QA

#Pendahuluan

Game kalian sudah punya gameplay, grafis, audio, dan multiplayer. Apakah sudah siap dirilis? Belum tentu — karena kualitas hanya bisa dijamin lewat pengujian. Game yang tidak diuji adalah game yang dipasang untuk gagal: satu bug crash di menit pertama membuat ulasan buruk yang menempel bertahun-tahun.

Episode ini membangun proses QA untuk Rimba Runner: playtesting (menguji dengan pemain nyata), bug tracking (mencatat dan memprioritaskan bug), dan automated testing (menguji dengan kode agar bug tidak kembali). Ini adalah disiplin yang membedakan hobi dari profesi.

#Playtesting: Menguji dengan Mata Segar

Playtesting adalah menguji game dengan pemain yang bukan developer. Ini terdengar sederhana, tapi paling sulit dipraktikkan dengan benar. Developer buta terhadap bug karena sudah tahu cara main; pemain baru menemukan semuanya — kontrol yang membingungkan, tujuan yang tidak jelas, atau lompatan yang mustahil.

Tiga aturan playtesting yang efektif:

• Jangan memandu — beri pemain tujuan minimal, lalu diam dan perhatikan. Keheningan saat pemain bingung adalah data paling berharga.
• Amati perilaku, bukan hanya kata-kata — pemain yang berkata "game-nya seru" tapi terlihat frustasi di menit ketiga memberi sinyal lebih jujur lewat tingkah laku.
• Rekam sesi — video letakkan kamera menghadap pemain + layar; developer bisa menonton ulang dan menangkap momen yang terlewat saat live.

Hasil playtest bukan sekadar daftar bug — ia juga masukan desain: "pemain tidak tahu harus ke mana", "tombol lompat terasa telat", "musuh terlalu cepat". Inilah umpan balik paling awal untuk iterasi desain, yang akan kita kerjakan lanjut di episode 17.

#Bug Tracking: Mencatat dan Memprioritaskan

Bug yang tidak tercatat adalah bug yang hilang. Setiap bug harus masuk sistem tracking dengan informasi yang cukup untuk direproduksi. Informasi wajib:

Praktik yang baik: gunakan tool tracking yang sudah ada — GitHub Issues, Jira, or Linear — dan tautkan bug ke commit yang memperbaikinya (fix #42). Ini menciptakan jejak: bug apa muncul di versi mana, diperbaiki oleh siapa, di commit apa. Dengan itu, regression (bug kembali) mudah ditelusuri.

Prioritaskan dengan matriks sederhana: severity × likelihood. Bug yang bikin crash dan sering terjadi dikerjakan dulu; masalah kosmetik langka boleh ditunda. Jangan biarkan daftar bug tak terurut — prioritas yang jelas membuat rilis tetap mungkin tercapai.

#Automated Testing

Playtesting tidak menangkap regression — bug yang kembali setelah perbaikan karena kode lain berubah. Di sinilah automated testing berperan. Untuk game, tiga level pengujian yang umum:

• Unit test — menguji satu fungsi/logika murni. Contoh: fungsi hitung skor, validasi rule, algoritma pathfinding.
• Integration test — menguji interaksi antar sistem. Contoh: menyentuh buah → skor naik → signal terpancar.
• End-to-end / smoke test — menjalankan scene secara otomatis dan memverifikasi hasil penting. Contoh: load level, tunggu 2 detik, pastikan tidak crash.

Contoh unit test di Godot (menggunakan skrip test bawaan):

unit_test.gd — menguji logika skor

extends SceneTree
 
func _init() -> void:
    var scorer := ScoreCalculator.new()
    assert(scorer.calculate_chain(3) == 60)   # 10 + 20 + 30
    assert(scorer.calculate_chain(0) == 0)
    print("Semua unit test lulus")
    quit()

Kunci automated testing: uji logika murni (pure logic) terlebih dahulu — bagian yang paling sering rusak dan paling mudah diuji tanpa UI. Fungsi hitung, validasi, dan state transition adalah kandidat sempurna. Menguji gerakan karakter butuh setup physics yang rumit; mulailah dari yang berharga dan murah.

#Siklus QA yang Realistis

QA bukan acara sekali jalan — ia siklus yang berulang sepanjang development. Siklus yang sehat untuk project indie:

1. Per-batch fitur — setiap fitur baru diuji playtest kecil + unit test.
2. QA pass terjadwal — seminggu sekali, mainkan seluruh build mengikuti checklist, catat semua bug.
3. Fix & regression test — perbaiki bug prioritas, tulis test, tandai selesai.
4. Ulang — sampai crash/major bug nol menjelang rilis.

Checklist QA Rimba Runner yang bisa dipakai:

[x] Semua level bisa diselesaikan tanpa bug blocker
[x] Save/load konsisten (restart game tidak hilang progres)
[x] Audio berhenti/berganti benar di menu, pause, game over
[x] UI tidak patah di resolusi utama & mobile
[x] Multiplayer join/leave tidak menimbulkan crash
[x] Tidak ada error di console sepanjang sesi

#Praktik: QA Pass Rimba Runner

Jalankan siklus QA pertama:

1. Playtest — minta 2-3 orang (bukan tim) memainkan build; rekam sesi; catat semua kebingungan & bug.
2. Bug tracking — buat GitHub Issues untuk tiap bug dengan steps + severity.
3. Unit test — tulis test untuk logika murni (skor, unlock, validasi).
4. Fix prioritas — perbaiki crash & major; tambahkan regression test.
5. Ulang pass — jalankan checklist sampai blocker nol.

#Penutup

QA adalah investasi reputasi.

Inti yang harus dibawa pulang:

• Playtesting dengan pemain nyata mengungkap hal yang tak terlihat developer; rekam dan amati perilaku.
• Bug tracking butuh steps, severity, dan environment agar reproducible dan terprioritaskan.
• Automated testing (unit → integration → smoke) mengunci bug agar tidak kembali.
• Siklus QA berulang: fitur → QA pass → fix → regression test → rilis.
• Mulai automated test dari logika murni; dokumentasikan checklist QA di repo.

Di episode 16 selanjutnya kita akan membuat game tetap mulus: performance & optimization game — profiling, draw calls, dan frame budget, lengkap dengan praktik optimasi Rimba Runner. Sampai jumpa di episode 16!