Jawaban singkatnya: pengujian perangkat lunak dan penjaminan mutu bukan tahap akhir sebelum serah terima — keduanya menentukan berapa biaya yang akan ditimbulkan sistem Anda setelah peluncuran. Dua sistem dengan anggaran yang sama persis berpisah jalan di satu titik: apakah sistem itu dibangun dengan cakupan pengujian yang menangkap cacat sebelum pelanggan Anda menemukannya, atau pelanggan Anda sendirilah rangkaian pengujiannya? Pada yang pertama, Anda membayar kualitas sekali saja selama pembangunan. Pada yang kedua, Anda membayarnya setiap bulan dalam bentuk gangguan layanan, perbaikan darurat, dan kepercayaan yang terkikis.

QA bukan "seseorang mengeklik ke sana kemari sebelum serah terima"

Gambaran umum di kalangan pemilik bisnis adalah bahwa kualitas berarti satu orang membuka layar-layar dan menekan tombol pada minggu terakhir proyek. Itu hanya bagian yang sangat kecil — dan paling tidak efektif — darinya. Penjaminan mutu yang sesungguhnya adalah sistem yang berjalan sejak hari pertama: kebutuhan yang ditulis cukup presisi agar dapat diuji, kode yang dicakup oleh pengujian otomatis yang berjalan pada setiap perubahan, lingkungan staging yang mencerminkan lingkungan produksi, dan jalur penerapan yang tidak akan membiarkan perubahan sampai ke produksi sebelum lolos dari gerbang-gerbang tersebut.

Perbedaan praktisnya sederhana: dalam pengaturan pertama, cacat muncul beberapa menit setelah ditulis; dalam pengaturan kedua, pelanggan Anda menemukannya sebulan kemudian, ketika Anda sudah membangun fitur-fitur lain di atas kesalahan yang sama.

Lapisan pengujian yang penting bagi Anda sebagai pengambil keputusan

Anda tidak diharapkan menguasai detail teknis, tetapi Anda diharapkan tahu apa yang Anda bayar. Inilah lapisan-lapisan yang harus disebutkan dalam setiap proposal teknis yang serius:

  • Uji unit: memverifikasi potongan logika terkecil secara terpisah. Uji ini paling cepat dan paling murah, dan inilah yang mencegah perubahan kecil merusak total faktur, diskon, atau perhitungan pajak.
  • Uji integrasi: memverifikasi bahwa bagian-bagian sistem berkomunikasi dengan benar satu sama lain dan dengan sistem eksternal — gerbang pembayaran, pengiriman, platform faktur, layanan pesan. Sebagian besar kegagalan di dunia nyata terjadi di sini, bukan di dalam kode itu sendiri.
  • Uji end-to-end: menyimulasikan perjalanan pengguna secara utuh dari awal hingga akhir, mulai dari membuka halaman hingga mengonfirmasi pesanan dan menerima notifikasi.
  • Uji kinerja dan beban: menjawab pertanyaan yang tidak dijawab oleh uji lain mana pun — apa yang terjadi ketika seribu pengguna datang pada menit yang sama, bukan sepuluh? Inilah lapisan yang sering dilewati tim, lalu sistem tumbang pada hari kampanye terbesar Anda.
  • Uji keamanan: memindai kerentanan umum sebelum orang lain menemukannya. Rujukan praktisnya adalah daftar OWASP Top 10 tentang risiko kritis aplikasi web; melihatnya disebut dalam rencana pengujian adalah tanda kematangan yang jelas.
  • Uji penerimaan pengguna: Anda dan tim Anda menjalankan sistem berdasarkan skenario bisnis Anda yang sebenarnya, bukan berdasarkan naskah ideal yang disiapkan pengembang. Tahap ini adalah tanggung jawab Anda, dan tidak boleh ada persetujuan sebelumnya.

Mengapa cacat makin mahal semakin terlambat Anda menemukannya

Siapa pun yang pernah menjalankan proyek perangkat lunak mengetahui aturannya: cacat yang tertangkap saat menulis kebutuhan diperbaiki dengan mengubah satu kalimat. Cacat yang sama jika tertangkap setelah peluncuran membutuhkan diagnosis, perbaikan, pengujian ulang, penerapan ulang — biasanya ditambah pemulihan data yang rusak di sepanjang jalan dan permintaan maaf kepada pelanggan yang terdampak. Masalahnya, selisih ini tidak pernah muncul dalam penawaran harga, sehingga vendor yang memangkas pengujian dari lingkup kerja terlihat lebih murah. Kenyataannya, mereka hanya menunda tagihan, dan memperbesarnya.

Pengujian otomatis versus manual: kapan menggunakan masing-masing

Pengujian manual sangat diperlukan untuk menilai pengalaman pengguna, kasus-kasus ekstrem, dan segala hal yang membutuhkan penilaian manusia. Namun pengujian manual tidak bisa menjadi jaring pengaman permanen, karena tidak ada yang akan memeriksa ulang dua ratus layar secara manual setelah setiap perubahan kecil. Pengujian otomatislah yang memungkinkan pengembangan berkelanjutan: Anda menulis pengujian sekali, pengujian itu berjalan ribuan kali, dan dalam hitungan menit memberi tahu Anda apakah perubahan hari ini merusak sesuatu yang dibangun tim Anda setahun lalu. Aturan praktisnya: otomatiskan semua hal berulang yang menyentuh uang atau data, dan serahkan pada penilaian manusia semua hal yang menyangkut bagaimana produk terasa saat digunakan.

Perhatikan data pengujian Anda

Ada satu persoalan yang lolos dari perhatian banyak tim tanpa diperiksa: menyalin basis data produksi ke lingkungan staging agar pengembang dapat melakukan pengujian dengannya. Artinya, nama, nomor telepon, dan alamat pelanggan Anda kini berada di lingkungan dengan akses lebih luas dan perlindungan lebih lemah. Undang-Undang Pelindungan Data Pribadi Arab Saudi, yang diawasi oleh Otoritas Data dan Kecerdasan Buatan Saudi (SDAIA), mengatur pemrosesan data pribadi apa pun sebutan Anda untuk lingkungan yang menyimpannya. Solusinya sederhana dan sudah dikenal: data yang dibuat secara sintetis, atau data asli yang kolom-kolom sensitifnya disamarkan sebelum disalin.

Apa yang harus diminta dari vendor sebelum menandatangani kontrak

  • Rencana pengujian tertulis di dalam lingkup pekerjaan, bukan janji lisan bahwa "sistem akan diuji".
  • Pengujian yang berjalan otomatis pada setiap perubahan melalui pipeline integrasi berkelanjutan, dengan penerapan diblokir ketika ada pengujian yang gagal.
  • Lingkungan staging yang terpisah dari lingkungan yang digunakan pelanggan, dengan penjelasan yang jelas tentang asal datanya.
  • Laporan cakupan berkala, dibaca baik sebagai persentase maupun sebagai arah: apakah cakupan meningkat seiring pertumbuhan sistem, atau menurun?
  • Masa garansi pascapeluncuran yang menetapkan apa yang dihitung sebagai cacat yang diperbaiki tanpa biaya dan apa yang merupakan permintaan pengembangan baru.

Tanda-tanda kualitas diabaikan dalam proyek Anda

Anda tidak memerlukan latar belakang teknis untuk mengenalinya: setiap perbaikan merusak hal lain, setiap penerapan didahului ketegangan yang terlihat dalam tim, tidak ada yang berani menyentuh modul lama "karena modul itu berfungsi dan kami tidak tahu apa dampaknya", dan gangguan layanan dilaporkan oleh pelanggan Anda, bukan oleh sistem pemantauan Anda. Ini bukan masalah yang terpisah — semuanya adalah gejala dari tidak adanya jaring pengujian yang memungkinkan tim melakukan perubahan dengan percaya diri.

Di Origami, kami memperlakukan cakupan pengujian sebagai bagian dari produk, bukan pos biaya dukungan: sistem yang tidak dapat diubah dengan aman dua tahun kemudian bukanlah sistem yang berhasil, sebagus apa pun tampilannya pada hari serah terima.

Sumber