Software Quality Metrics: Ketika Game yang Indah Memiliki Masalah Optimasi

Membahas bagaimana Software Quality Metrics membantu mengukur performa, stabilitas, dan kualitas game modern seperti Wuthering Waves di tengah masalah optimasi yang sering dikeluhkan pemain.

Visual Memukau Namun ‘Berat’: Tantangan Pengembang dalam Menyeimbangkan Grafis dan Performa.

Tanggal 22 Mei 2024. Jutaan pemain di seluruh dunia, termasuk lebih dari 30 juta orang yang sudah pre-register, akhirnya bisa membuka Wuthering Waves, game action RPG open-world gacha besutan Kuro Games yang sudah dinanti-nantikan selama bertahun-tahun.

Lalu, kekacauan pun dimulai.

Dalam 16 jam pertama sejak peluncuran, thread “Launch Technical Issues Megathread” di Reddit sudah kebanjiran 3.400+ komentar. Pemain melaporkan crash fatal dengan pesan error “UE4 Client Game Has Crashed”, ping melonjak hingga 1.000ms bahkan di server Asia Tenggara, stuttering parah di PC berspesifikasi tinggi, tekstur buram, cutscene yang terpotong tiba-tiba, animasi karakter yang kakinya menembus lantai, hingga perangkat Android yang kepanasan hanya dari memainkan tutorial.

Tampilan login screen Wuthering Waves yang memukau secara visual, tetapi juga menjadi awal dari berbagai diskusi pemain mengenai performa dan optimasi game.

Kuro Games merespons dengan permintaan maaf resmi dan kompensasi berupa 10 Lustrous Tide (10 pull gratis) kepada semua pemain. Sebuah respons yang diapresiasi komunitas, tapi yang tidak bisa menjawab satu pertanyaan mendasar:

Bagaimana sebuah game yang dikembangkan selama bertahun-tahun bisa dirilis dalam kondisi seperti ini? Dan lebih penting lagi, bagaimana seharusnya kualitas software diukur dan dikelola agar ini tidak terjadi?

Di sinilah Software Quality Metrics (SQM) menjadi relevan. Mari kita bedah.

Definisi Software Quality Metrics (SQM)

Sebelum masuk ke analisis, kita perlu membangun fondasi yang sama.

Dalam dunia rekayasa perangkat lunak, ada tiga istilah yang sering tertukar namun punya makna berbeda:

Measurement adalah tindakan mengumpulkan data. Contohnya: mencatat bahwa terjadi 847 crash report dalam satu hari pertama peluncuran Wuthering Waves.

Measure adalah indikasi kuantitatif dari suatu atribut. Contohnya: 847 crash adalah sebuah measure dari atribut “stabilitas sistem”.

Metric, inilah yang dimaksud SQM, adalah ukuran kuantitatif yang sudah diperhitungkan secara bermakna. Menurut IEEE Software Engineering Standards (1993), metric adalah “a quantitative measure of the degree to which a system, component, or process possesses a given attribute.” Contohnya: 0,028 crash per sesi bermain (jika total sesi hari pertama adalah 30 juta).

Sederhananya, SQM adalah sistem pengukuran terstruktur yang mengubah pertanyaan subjektif seperti “seberapa bagus kualitas game ini?” menjadi angka-angka konkret yang bisa dibandingkan, dilacak, dan dijadikan dasar keputusan.

Tom DeMarco merangkumnya dengan elegan pada 1982:

“If you can’t measure it, you can’t manage it.”

Dan itulah masalah terbesar Wuthering Waves di hari pertama: bukan bahwa tidak ada metrik, tapi metrik yang tepat kemungkinan besar tidak digunakan atau tidak ditindaklanjuti.

Masalah apa yang dapat diselesaikan dengan menggunakan SQM dan kenapa SQM dibutuhkan

Autopsi Kegagalan Wuthering Waves di Hari Pertama

Mari kita inventarisir apa yang terjadi dan kaitkan dengan dimensi kualitas yang gagal diukur atau dikelola:

• Crash fatal “UE4 Has Crashed” di PC high end: Kegagalan pada dimensi Reliability atau Stabilitas.
• Ping 150 sampai 1.000ms di server Asia Tenggara: Kegagalan pada dimensi Performance atau Kapasitas server.
• Stuttering parah bahkan di RTX 3080: Kegagalan pada dimensi Performance atau Optimasi rendering.
• Tekstur buram dan NPC placeholder: Kegagalan pada dimensi Completeness atau Kesiapan konten.
• Cutscene terpotong tiba tiba: Kegagalan pada dimensi Correctness atau Integrasi sistem.
• Android overheating dari tutorial: Kegagalan pada dimensi Efficiency atau Resource management.
• Login Timeout setiap kali relaunch di PC: Kegagalan pada dimensi Usability atau UX consistency.

Ini bukan satu atau dua masalah terisolasi. Ini adalah kegagalan kualitas sistemik yang seharusnya bisa ditangkap jauh lebih awal dengan SQM yang tepat.

Empat Masalah Utama yang Diselesaikan SQM

1. Tidak Ada Standar “Cukup Baik” yang Terukur: Tanpa SQM, “siap rilis” hanya berarti “menurut kita sudah oke.” Dengan SQM, “siap rilis” berarti “crash rate di bawah 0,01 per sesi, frame rate stabil di atas 30fps pada hardware minimum, dan DERE (error removal effectiveness) di atas 85%.”
2. Prioritas Perbaikan yang Keliru: Jika semua bug diperlakukan sama, tim QA bisa menghabiskan waktu memperbaiki typo di menu pengaturan sementara crash fatal dibiarkan. SQM, melalui metric seperti error severity, memastikan bug yang menyebabkan game tidak bisa dimainkan (game-breaking) diprioritaskan jauh di atas bug kosmetik.
3. Tidak Bisa Membuktikan “Sudah Membaik”: Saat Kuro Games merilis patch setelah hari pertama, bagaimana mereka tahu patch itu benar-benar berhasil? Tanpa baseline metric yang jelas, jawabannya hanya “laporan crash berkurang.” Dengan SQM, jawabannya bisa lebih kuat: “SSFD turun dari 28,3 menjadi 4,1 per 1.000 jam bermain.”
4. Estimasi dan Perencanaan yang Tidak Akurat: Wuthering Waves dikembangkan dengan UE4 yang dimodifikasi berat, menambahkan fitur-fitur UE5 seperti sistem Lumen-inspired GI secara manual. Tanpa metrik produktivitas dan timetable yang solid, sangat mudah untuk salah mengestimasi kapan sebuah fitur kompleks benar-benar siap.

Kenapa SQM Dibutuhkan

Menurut Galin (2004) dalam Software Quality Assurance: From Theory to Implementation, SQM dibutuhkan untuk:

• Menentukan kualitas aktual suatu software atau dokumentasi secara objektif
• Mengukur kualitas kerja tim. Programmer, QA engineer, project manager
• Mendorong perbaikan kualitas produk, proyek, dan proses secara berkelanjutan
• Membuktikan nilai dari tools atau metodologi engineering baru
• Menutup kesenjangan kualitas melalui pelatihan yang tepat sasaran

Singkat kata: tanpa SQM, pengelolaan kualitas hanyalah tebak-tebakan yang dibungkus dalam istilah profesional.

Tujuan Penggunaan SQM

SQM memiliki dua tujuan besar yang saling melengkapi:

Tujuan 1: Mendukung Kontrol, Perencanaan, dan Intervensi Manajerial

Bayangkan Project Manager Kuro Games yang memantau status pengembangan Version 1.0. Dengan SQM, ia seharusnya bisa melihat metrik seperti:

• TTO (Timetable Observance): berapa persen milestone yang selesai tepat waktu
• ADMC (Average Delay of Milestone Completion): rata-rata keterlambatan per milestone
• Error density trends: apakah jumlah bug baru yang ditemukan di QA naik atau turun setiap minggu

Jika data menunjukkan bahwa error density masih tinggi tiga minggu sebelum tanggal rilis, maka PM memiliki dasar yang kuat untuk memutuskan: “Tunda dua minggu”, sebuah keputusan yang terasa pahit tapi jauh lebih murah daripada menanggung badai negatif dari launch yang buruk, kompensasi massal, dan reputasi yang tercoreng.

Tujuan 2: Mengidentifikasi Peluang Perbaikan Proses Secara Jangka Panjang

Data metrik yang dikumpulkan dari berbagai versi Wuthering Waves dapat membentuk pola yang invaluable. Misalnya:

• Jika bug terbanyak selalu muncul di sistem combat (DMG calculation, hitbox detection), ini mengindikasikan bahwa proses code review untuk modul tersebut perlu diperkuat.
• Jika error rate selalu melonjak setelah feature freeze, ini mengindikasikan bahwa proses testing regresi tidak memadai.
• Jika server-side failures selalu terjadi di hari pertama setiap patch baru, ini mengindikasikan masalah di proses load testing.

Pola-pola ini tidak bisa terlihat tanpa data metrik yang konsisten dan longitudinal.

Proses Umum Penilaian Kualitas dengan SQM

Mendefinisikan dan menggunakan SQM bukanlah kegiatan satu kali, ini adalah siklus empat langkah yang terus berputar:

1. Tentukan atribut yang ingin diukur.
2. Definisikan metrik yang mengukur atribut tersebut.
3. Tentukan target nilai komparatif atau indikator.
4. Definisikan metode pelaporan dan pengumpulan data metrik.

Siklus ini bersifat iteratif dan merespons perkembangan organisasi serta lingkungannya.

Jenis Jenis SQM dan Contoh Penggunaannya

A. Process Metrics (Mengukur Efektivitas Proses Development)

Process metrics dikumpulkan lintas proyek dalam jangka panjang. Tujuannya bukan memantau satu proyek, tapi meningkatkan cara kerja tim secara berkelanjutan.

• TTO (Time Table Observance): Jumlah milestone selesai tepat waktu dibagi total milestone. Jika hanya 2 dari 5 milestone selesai tepat waktu, nilainya adalah 0,4.
• ADMC (Average Delay of Milestone Completion): Total keterlambatan dibagi jumlah milestone.

B. Project Metrics (Memantau dan Mengendalikan Proyek Berjalan)

Project metrics membantu manajer mengambil keputusan berbasis data, bukan intuisi.

KLOC dan NFP sebagai denominator. Hampir semua metrik kualitas menggunakan KLOC (Kilo Lines of Code) atau NFP (Number of Function Points) sebagai denominator. Wuthering Waves sebagai game AAA dengan open world, sistem combat kompleks, dan multiplayer kemungkinan memiliki puluhan juta baris kode, menjadikan normalisasi berbasis KLOC atau NFP sangat penting agar perbandingan antar tim atau antar versi menjadi bermakna.

• DevP (Development Productivity): Total jam kerja pengembangan dibagi KLOC. Metrik ini penting untuk mendeteksi bottleneck. Jika modul rendering Wuthering Waves membutuhkan 5× lebih banyak jam kerja per KLOC dibanding modul UI, ini adalah sinyal bahwa ada masalah di arsitektur rendering yang perlu perhatian, sesuatu yang memang terbukti menjadi masalah utama game ini (UE4 yang dimodifikasi dengan fitur Lumen-inspired GI custom).

C. Product Metrics (Mengukur Kualitas Produk)

Kategori ini merupakan yang paling relevan dengan pengalaman pemain secara langsung karena mengukur atribut produk pada berbagai tahap pengembangan.

C.1 Error Density Metrics, Seberapa Banyak Bug?

Metrik ini membantu mengukur kepadatan kesalahan dalam kode.

• CED (Code Error Density) dihitung dengan membagi NCE (jumlah kesalahan kode) dengan KLOC (ribuan baris kode).
• WCED (Weighted Code Error Density) dihitung dengan membagi WCE (total kesalahan kode berbobot) dengan KLOC.

Penggunaan bobot keparahan (severity) yaitu Low (1), Medium (3), dan High (15) sangat tepat karena sesuai dengan contoh perhitungan produktivitas programmer dalam materi. Studi kasus antara Tim Alpha dan Tim Beta yang Anda buat secara akurat mengilustrasikan bahwa jumlah bug yang sedikit belum tentu menjamin kualitas jika tingkat keparahannya tinggi.

C.2 Error Severity Metrics, Seberapa Parah Bug yang Ada?

Metrik ini memberikan indikasi kualitas teknis melalui rata-rata keparahan kesalahan.

• ASCE (Average Severity of Code Errors) dihitung dengan membagi WCE dengan NCE. Nilai ASCE yang tinggi menandakan bahwa kesalahan yang ditemukan cenderung serius.
• ASDE (Average Severity of Development Errors) dihitung dengan membagi WDE (total kesalahan pengembangan berbobot) dengan NDE (total kesalahan pengembangan). Ini mencakup kesalahan desain dan kode di seluruh proses pengembangan.

C.3 Error Removal Effectiveness Metrics, Seberapa Efektif QA Menangkap Bug?

Metrik ini memberikan indikasi mengenai efektivitas tim pengembang dalam mendeteksi dan memperbaiki kesalahan sebelum produk sampai ke tangan pengguna.

• DERE (Development Error Removal Effectiveness) dihitung dengan membagi NDE dengan hasil penjumlahan NDE dan NYF. Metrik ini menunjukkan persentase kesalahan yang berhasil disaring selama proses pengembangan.
• DWERE (Development Weighted Errors Removal Effectiveness) dihitung dengan membagi WDE dengan hasil penjumlahan WDE dan WYF. Ini memberikan penilaian yang lebih akurat dengan mempertimbangkan bobot tingkat keparahan dari setiap kesalahan yang ditemukan.

C.4 Timetable Metrics, Apakah Pengembangan On-Schedule?

Sudah dibahas di atas (TTO dan ADMC), namun penting ditegaskan bahwa timetable yang meleset secara konsisten adalah salah satu faktor terbesar yang memaksa tim untuk merilis software dalam kondisi tidak siap, persis seperti yang diduga banyak analis terjadi pada Wuthering Waves.

C.5 Productivity Metrics, Seberapa Efisien Tim Bekerja?

Metrik produktivitas membantu mengidentifikasi efisiensi penggunaan sumber daya dalam pengembangan.

• CRe (Code Reuse) dihitung dengan membagi ReKLOC (jumlah ribuan baris kode yang digunakan ulang) dengan KLOC.
• Penggunaan kode yang sudah teruji dari proyek sebelumnya, seperti dari Punishing: Gray Raven, secara teori dapat meningkatkan stabilitas karena mengurangi peluang munculnya kesalahan baru dari awal.

D. Maintenance Metrics (Mengukur Kualitas Setelah Rilis)

• HDD (Help Desk Calls Density): Jumlah tiket support per tahun dibagi KLOC.
• FA (Full Availability): Persentase waktu server aktif penuh dalam setahun.
• VitA (Vital Availability): Khusus mengukur ketersediaan fungsi vital seperti login server, sistem gacha, dan penyimpanan progress pemain. Nilai ini harus lebih tinggi dari FA — fungsi vital tidak boleh down meskipun fitur sekunder sedang bermasalah.
• SSFD (Software System Failure Density): Jumlah kegagalan sistem per tahun dibagi KLOC yang dipelihara.

Kesimpulan:

Wuthering Waves adalah contoh yang jelas bahwa kualitas software tidak hanya ditentukan oleh gameplay atau visual, tetapi juga oleh seberapa baik kualitas sistemnya diukur dan dikelola. Meskipun combat system-nya dipuji banyak pemain, masalah seperti crash, lag, overheating, dan server down menunjukkan pentingnya penerapan Software Quality Metrics (SQM) secara serius sejak awal pengembangan.

Dari kasus ini, ada beberapa pelajaran penting yang bisa dipahami. Pertama, severity bug lebih penting daripada jumlah bug. Satu bug besar yang membuat game tidak bisa dimainkan jauh lebih berbahaya dibanding banyak bug kecil. Kedua, efektivitas QA diukur dari seberapa sedikit bug yang lolos ke pemain, bukan hanya dari banyaknya bug yang ditemukan. Ketiga, keterlambatan jadwal pengembangan sering menjadi tanda adanya masalah kualitas yang belum selesai. Dan terakhir, metrik pasca-rilis seperti stabilitas server dan jumlah crash tetap penting untuk menjaga kepuasan pemain.

Meski sempat mengalami launch yang bermasalah, Wuthering Waves perlahan berhasil memperbaiki performa dan optimasinya melalui berbagai update. Hal ini membuktikan bahwa perbaikan kualitas software memang memungkinkan, tetapi prosesnya membutuhkan waktu, biaya, dan usaha yang besar.

Seperti kata Tom DeMarco:

“If you can’t measure it, you can’t manage it.”

Karena tanpa pengukuran kualitas yang tepat, masalah software pada akhirnya akan dirasakan langsung oleh para pengguna.

Referensi:

• Galin, D. (2004). Software Quality Assurance: From Theory to Implementation. Pearson Education.
• IEEE Std 1061–1998. IEEE Standard for a Software Quality Metrics Methodology.
• Dexerto. (2024). Wuthering Waves players slam “unfinished” and buggy launch.
• PC Gamer. (2024). Wuthering Waves is suffering from some catastrophic launch issues.
• Steam Community Discussions. (2025). Performance problems? :: Wuthering Waves.
• Reddit r/WutheringWaves. (2024). Launch Technical Issues Megathread.
• ToonXD Analysis. (2026). Wuthering Waves Performance & Stutter: Engine Architecture.