Dua vendor software bisa menawarkan harga yang persis sama untuk fitur yang persis sama, tapi satu vendor bisa merilisnya dalam dua minggu tanpa satu pun insiden produksi, sementara vendor lain butuh enam minggu dan tetap merusak sesuatu di hari rilis. Automated testing adalah alasan di balik kesenjangan itu, dan ini nyaris tidak pernah menjadi pertanyaan yang terpikir oleh pemilik bisnis sebelum tanda tangan kontrak.

Saya pernah berada di kedua sisi ini. Sebagai technical lead, saya pernah mewarisi sistem tanpa test coverage sama sekali dan menyaksikan setiap rilis berubah jadi acara all-hands yang penuh tekanan. Saya juga pernah membangun sistem dengan automated test yang kuat, di mana seorang developer junior bisa merilis perubahan di Jumat sore dengan percaya diri, karena test-nya menangkap hal-hal yang bahkan luput dari mata reviewer manusia.

Anda tidak perlu bisa menulis kode untuk memahami ini. Anda hanya perlu tahu pertanyaan apa yang harus diajukan ke vendor Anda, dan seperti apa jawaban yang sehat.

Apa Itu Automated Testing, dalam Bahasa Sederhana

Automated test adalah kode yang memeriksa kode lain. Alih-alih seorang QA mengklik satu per satu bagian aplikasi secara manual setiap kali ada perubahan untuk memastikan tidak ada yang rusak, serangkaian automated test berjalan dalam hitungan menit dan memeriksa ratusan atau ribuan skenario: apakah perhitungan diskon masih berfungsi, apakah login masih menolak password yang salah, apakah total invoice masih cocok setelah perubahan tarif pajak.

Test ini bukan lapisan tambahan yang sifatnya nice-to-have di akhir proses. Di tim engineering yang dikelola dengan baik, test ditulis bersamaan dengan fitur, kadang bahkan sebelum fitur itu dibuat, dan berjalan otomatis setiap kali ada yang mengajukan perubahan.

Analogi Fondasi Bangunan

Tanyakan ke kontraktor tentang pekerjaan fondasi mereka, dan kontraktor yang kompeten akan memberi jawaban spesifik: kedalaman, jarak tulangan besi, waktu curing, perhitungan beban. Kontraktor yang tidak kompeten atau suka mengambil jalan pintas akan mengelak dengan "sudah aman kok, percaya saja."

Tanyakan ke vendor software tentang test coverage, dan polanya sama. Tim yang serius soal kualitas akan memberi jawaban spesifik: berapa persen codebase yang tercakup, jenis test apa saja yang dijalankan (unit, integration, end-to-end), dan apa yang terjadi secara otomatis sebelum kode sampai ke produksi. Tim yang suka mengambil jalan pintas akan bilang sesuatu seperti "kami test semua secara manual sebelum rilis" lalu mengalihkan topik.

Fondasi bangunan tidak terlihat sampai gedungnya bermasalah. Test coverage juga tidak terlihat sampai software Anda bermasalah, dan pada titik itu biayanya sudah mahal dan sudah jadi konsumsi publik.

Biaya dari Tanpa Test, secara Konkret

Saya pernah mengambil alih proyek untuk sebuah jaringan ritel di Tangerang, yang vendor sebelumnya membangun mesin promosi tanpa automated test sama sekali. Setiap perubahan aturan harga membutuhkan pengujian manual puluhan kombinasi satu per satu, dan tetap saja sekitar satu dari empat rilis mengalami masalah, biasanya baru ketahuan dari kasir di kasir, bukan dari tim QA.

Biaya langsungnya:

  • Rilis jadi lebih lambat. Setiap perubahan membutuhkan pengujian regresi manual, mengubah fitur yang seharusnya selesai dalam dua jam menjadi siklus rilis dua hari.
  • Insiden di produksi. Harga salah saat checkout, kadang pelanggan dikenakan harga lebih murah selama berhari-hari sebelum ada yang sadar.
  • Development yang dijalankan dari rasa takut. Developer jadi enggan menyentuh kode lama karena tidak ada yang bisa memastikan apa yang akan rusak, sehingga codebase makin kaku dan sulit diubah.
  • Onboarding jadi berat. Developer baru tidak punya jaring pengaman untuk belajar sistem; setiap perubahan terasa seperti lompatan tanpa kepastian.

Kami membangun ulang logic pricing inti dengan test suite yang mencakup seluruh business rule. Siklus rilis turun dari dua hari kembali ke hitungan jam. Insiden pricing di produksi turun ke hampir nol dalam setahun berikutnya. Biaya di awal untuk menulis test itu nyata, tapi jauh lebih kecil dibanding satu insiden pricing yang salah dalam skala besar.

Seperti Apa Jawaban yang Sehat dari Vendor

Saat Anda bertanya ke vendor atau tim internal soal testing, dengarkan baik-baik apakah jawabannya sespesifik ini:

Sinyal sehat Sinyal peringatan
"Kami menjalankan automated test di setiap perubahan sebelum di-merge." "Kami test manual sebelum tiap rilis."
"Coverage sekitar 70-80% di business logic inti." "Kami tidak benar-benar melacak angka itu."
"Test berjalan otomatis di CI pipeline kami, dalam hitungan menit." "QA melakukan pengujian penuh, butuh sekitar seminggu."
Bisa menyebutkan bagian mana yang TIDAK ditest dan alasannya (tradeoff yang nyata) Mengklaim semuanya sudah fully tested (kecil kemungkinan itu benar)
Bug yang ditemukan langsung ditambahkan test-nya supaya tidak terulang diam-diam Kategori bug yang sama terus berulang di setiap rilis

Tidak ada yang punya coverage 100%, dan itu wajar. Yang penting adalah tim bisa memberi tahu Anda dengan jujur di mana celahnya dan kenapa, sama seperti kontraktor yang seharusnya bisa menjelaskan bagian mana dari bangunan yang membawa risiko lebih besar.

Kenapa Ini Penting untuk Kecepatan Delivery, Bukan Cuma Kualitas

Bagian yang terdengar kontraintuitif: automated testing yang kuat justru membuat delivery lebih cepat, bukan lebih lambat. Tim tanpa test akan makin melambat seiring waktu ketika codebase membesar, karena setiap perubahan butuh lebih banyak verifikasi manual agar terasa aman. Tim dengan test bisa bergerak dengan kecepatan yang nyaris konstan selama bertahun-tahun, karena test suite yang melakukan pekerjaan verifikasi yang seharusnya diulang dari nol oleh manusia di setiap rilis.

Jika vendor Anda saat ini makin lambat dalam delivery seiring lamanya kerja sama, itu sering kali jadi tandanya. Ini layak diangkat secara langsung, dan merupakan poin yang sah untuk dinegosiasikan ulang saat perpanjangan kontrak, bersanding dengan poin-poin lain yang dibahas di panduan negosiasi kontrak software. Ini juga pertanyaan yang wajar diajukan saat tinjauan anggaran teknologi triwulanan, karena kecepatan delivery yang melambat tetap merupakan biaya meskipun tidak muncul di baris anggaran mana pun.

Yang Perlu Dilakukan

Ajukan satu pertanyaan ke vendor atau tim internal Anda di tinjauan proyek berikutnya: "Berapa persen business logic inti yang tercakup oleh automated test, dan apa yang terjadi secara otomatis sebelum kode sampai ke produksi?" Jawaban yang spesifik dan percaya diri adalah tanda baik. Jawaban yang samar, atau yang berbelok ke "kami test manual," adalah sinyal bagi Anda untuk mengajukan pertanyaan yang lebih tajam sebelum perpanjangan kontrak berikutnya, bukan setelah insiden produksi berikutnya terjadi.