Setiap beberapa bulan, seorang pemilik bisnis melihat anggaran proyek, menemukan pos biaya QA, lalu mengajukan pertanyaan yang terdengar masuk akal: "Developer kan sudah menguji kodenya sendiri, bisa dipangkas gak biaya ini?" Saya paham dorongan di baliknya. QA terlihat seperti asuransi yang Anda bayar dan berharap tidak pernah perlu dipakai. Tapi nilai qa testing dalam software sebenarnya bukan soal mencari bug. Ini soal melindungi tiga hal yang benar-benar menghabiskan uang Anda ketika software bermasalah: peluncuran Anda, reputasi Anda, dan tim support Anda.
Biar saya jelaskan dengan angka yang bisa Anda rasakan, karena argumen abstrak jarang mengena.
Saat Anda memangkas QA, Anda tidak menghilangkan biaya kualitas. Anda hanya menundanya, dengan bunga. Bug yang tertangkap sebelum rilis hanya menghabiskan satu jam waktu tester. Bug yang sama, kalau tertangkap oleh pelanggan saat checkout, menghabiskan jam kerja support, refund, perbaikan darurat, dan kerusakan kepercayaan yang tidak bisa Anda tagihkan ke siapa pun. Melewatkan QA sama dengan berutang, dan production mengenakan bunga yang kejam.
Testing developer dan QA bukan pekerjaan yang sama
Ini adalah kesalahpahaman di akar setiap percakapan "boleh dipangkas gak". Betul, developer yang baik menguji kodenya sendiri. Tapi mereka mengujinya untuk membuktikan bahwa kode itu berfungsi. QA mengujinya untuk membuktikan bahwa kode itu rusak. Itu dua pola pikir yang berlawanan, dan Anda butuh keduanya.
- Developer mengecek bahwa memasukkan nomor telepon yang valid berhasil menyimpan data pelanggan. Itu konfirmasi.
- Tester QA memasukkan nomor telepon berisi huruf, lalu kolom kosong, lalu string 200 karakter, lalu submit dua kali dengan cepat, lalu memutuskan koneksi di tengah proses simpan. Itu cara berpikir adversarial.
Pelanggan Anda bersikap adversarial tanpa sengaja. Mereka salah pencet, pakai HP lama, sinyal hilang di dalam lift, paste karakter aneh, dan membuka aplikasi dengan cara yang tidak pernah dirancang oleh siapa pun. QA adalah disiplin untuk berperilaku seperti pelanggan skenario-terburuk Anda sebelum pelanggan skenario-terburuk itu benar-benar melakukannya. Developer yang baru saja menulis sebuah fitur, secara wajar, adalah orang yang paling sulit melihat bagaimana fitur itu bisa gagal.
Sebenarnya berapa biaya satu bug di production
Berikut rangkaian kejadian yang realistis untuk bisnis Indonesia skala menengah yang merilis bug pembayaran ke production pada Jumat sore.
| Biaya | Yang terjadi | Perkiraan angka |
|---|---|---|
| Lonjakan support | 40 pelanggan bingung menghubungi selama akhir pekan | 15 hingga 20 jam kerja staf |
| Transaksi gagal | Pesanan gagal diam-diam; sebagian pelanggan langsung pergi | Penjualan hilang, sulit dipulihkan |
| Refund dan goodwill | Anda refund dan menambah kredit untuk menjaga pelanggan | Rp 3 juta sampai 10 juta, dengan mudah |
| Perbaikan darurat | Developer ditarik dari pekerjaan yang sudah direncanakan, tarif akhir pekan | Keterlambatan berhari-hari di pekerjaan lain |
| Reputasi | Beberapa ulasan bintang satu dan tangkapan layar beredar di grup chat | Tak terhitung, dan efeknya bertahan lama |
Bandingkan dengan biaya untuk menangkapnya lebih awal: seorang tester menjalankan alur pembayaran dengan kartu ditolak, timeout, dan double-tap, menemukan kegagalannya, melaporkannya, dan bug itu diperbaiki sebelum ada satu pun orang di luar tim yang melihatnya. Dua puluh menit berbanding satu akhir pekan yang hilang dan reputasi yang babak belur. Rasio itulah keseluruhan argumen untuk QA, dan itu terbukti benar hampir setiap saat.
Reputasi adalah biaya yang tidak pernah muncul di invoice
Biaya langsung memang menyakitkan tapi masih bisa dipulihkan. Yang diam-diam terus membesar adalah kepercayaan. Di Indonesia, word of mouth bergerak cepat dan tangkapan layar bergerak lebih cepat lagi. Checkout yang mengenakan biaya dua kali, aplikasi yang kehilangan pesanan, formulir yang menghabiskan satu jam waktu seseorang, semua ini tidak sekadar menghasilkan satu tiket support. Semua ini menghasilkan cerita yang diceritakan pelanggan Anda kepada orang lain.
Anda tidak akan pernah menerima invoice berjudul "kerusakan reputasi". Justru karena itulah hal ini sering diremehkan dalam rapat anggaran. QA adalah cara Anda mempertahankan aset yang tidak muncul di neraca sampai aset itu sudah tergerus. Ini terhubung dengan poin yang sering saya sampaikan, bahwa masalah kualitas yang dibiarkan adalah bentuk utang teknis yang membuat aplikasi Anda makin lambat diperbaiki seiring waktu. Testing yang dilewatkan adalah salah satu cara tercepat untuk menumpuk utang itu.
Yang sebenarnya diberikan oleh QA yang baik
Ketika QA dijalankan dengan baik, Anda bukan membayar seseorang untuk klak-klik sembarangan. Anda membayar untuk proses keamanan yang bisa diulang, yang melindungi setiap rilis:
- Cakupan pengujian pada alur yang benar-benar penting. Checkout, login, pembayaran, dan apa pun yang menyentuh uang diuji secara ketat, di setiap rilis, dengan cara yang tertulis dan bisa diulang.
- Gerbang sebelum peluncuran. Ada orang yang tugasnya berkata "belum boleh" dan punya otoritas untuk mengatakannya. Satu checkpoint itu saja mencegah sebagian besar bencana malam Jumat.
- Perlindungan regresi. Fitur baru punya kebiasaan merusak fitur lama. QA menangkap hal yang bahkan tidak Anda pikirkan.
- Realitas perangkat sungguhan. Pelanggan Anda tidak semua pakai iPhone terbaru. QA di HP Android murah yang benar-benar dipakai pasar Anda memunculkan masalah yang tidak pernah dilihat tim Anda di laptop mereka sendiri.
- Laporan bug yang jelas dan bisa direproduksi. Tester yang baik menyerahkan bug ke developer dalam bentuk yang bisa diperbaiki dalam satu jam, bukan keluhan samar yang harus dikejar seharian.
Itulah nilai qa testing yang sebenarnya Anda beli. Bukan mencari bug sebagai hobi, tapi perlindungan peluncuran sebagai sebuah layanan.
Kapan QA yang lebih ringan memang cukup
Saya tidak akan berpura-pura bahwa setiap proyek butuh tim QA penuh. Bersikap jujur soal ini justru bagian dari menjaga kepercayaan. Kalau Anda meluncurkan tool internal yang dipakai lima orang yang bisa memaklumi sedikit kekurangan, QA berat itu berlebihan dan saya akan bilang begitu. Taruhannya yang menentukan besarnya investasi:
- Ada uang, data pribadi, atau reputasi publik yang dipertaruhkan? QA tidak bisa ditawar.
- Internal, taruhan rendah, pengguna yang toleran? Testing developer yang lebih ringan ditambah satu kali pengecekan manual biasanya sudah cukup.
Kesalahannya bukan "memiliki QA yang lebih sedikit". Kesalahannya adalah memangkas QA pada sistem yang menghadapi pelanggan dan menyentuh uang demi menghemat satu pos anggaran, lalu membayar tiga kali lipat ketika sistem itu bermasalah di depan orang-orang yang justru ingin Anda menangkan hatinya.
Kesimpulan praktis
QA testing bukan pajak atas proyek Anda. Ini adalah titik termurah di sepanjang linimasa untuk menangkap sebuah kegagalan. Bug yang sama menjadi kira-kira sepuluh kali lebih mahal di setiap tahap yang ia lewati, dari developer ke tester ke pelanggan ke pengacara. Ketika Anda melihat pos biaya QA itu, jangan tanya "bisakah biaya ini dihilangkan?" Tanyakan "apakah kita mau membayar ini sekarang dengan harga retail, atau nanti dengan bunga?" Untuk apa pun yang menyentuh uang atau nama Anda, bayar sekarang.
Kalau Anda sedang menyusun scope sebuah proyek dan ingin masukan jujur soal seberapa besar QA yang benar-benar dibutuhkan proyek Anda, penentuan takaran itu adalah bagian dari cara saya membantu partner. Mulai percakapannya di halaman partner.