Seorang klien pernah bertanya kepada saya, setelah keluhan pelanggan ketiga dalam seminggu tentang alur pembayaran yang sama, "bagaimana ini bisa dikirimkan?" Ini adalah pertanyaan yang wajar, dan jawabannya hampir tidak pernah dramatis. Dasar-dasar jaminan kualitas perangkat lunak tidaklah eksotik, sebagian besar bersifat disiplin, dan bug yang menjangkau pelanggan Anda biasanya lolos melalui celah yang sepenuhnya terlihat sebelumnya, jika ada yang mencarinya.
Pemilik yang bukan insinyur cenderung menganggap bug adalah keniscayaan teknis, biaya dalam menjalankan bisnis dengan perangkat lunak. Beberapa memang demikian. Sebagian besar, menurut pengalaman saya, adalah kegagalan proses dengan mengenakan kostum teknis. Pengembang menguji jalur yang menyenangkan, tenggat waktu yang ketat, tidak ada orang di luar tim pembuat yang melihatnya sebelum diluncurkan, dan sekarang pelanggan Andalah yang mengetahui apa yang rusak.
Ekonomi tidak ada yang menjelaskan kepada pemilik
Ada aturan praktis dalam rekayasa perangkat lunak yang diterapkan secara longgar tetapi tetap berlaku dalam praktiknya: bug yang ditemukan saat sedang ditulis memerlukan biaya perbaikan sekitar satu unit. Ditemukan dalam pengujian sebelum rilis, harganya beberapa kali lipat. Ditemukan setelah pelanggan menemukannya, biayanya jauh lebih mahal, tidak hanya dalam waktu teknis tetapi juga dalam tiket dukungan, pengembalian uang, dan biaya yang lebih tenang bagi pelanggan yang tidak kembali.
Hal ini bukan karena perbaikannya sendiri menjadi lebih sulit. Itu karena segala sesuatu di sekitar perbaikan menjadi lebih sulit. Bug yang tertangkap dalam pengujian adalah perubahan kode yang terisolasi. Bug yang tertangkap dalam produksi adalah sebuah insiden: seseorang harus memperhatikannya, mereproduksinya, melakukan triase tingkat keparahannya, berkomunikasi dengan pelanggan yang terkena dampak, menambalnya di bawah tekanan, dan kemudian menjelaskan kepada Anda mengapa hal itu terjadi. Perbaikan kode sebenarnya mungkin terdiri dari lima baris dalam kedua kasus. Segala sesuatu yang mengelilingi kelima garis tersebut adalah tempat dimana biaya sebenarnya berada.
Ini adalah argumen ekonomi untuk QA yang jarang didengar oleh pemilik yang dinyatakan dengan jelas: setiap bug yang ditemukan kemudian harganya kira-kira sepuluh kali lebih mahal daripada bug yang ditemukan sebelumnya. Ini bukan argumen kualitas yang lunak, ini adalah argumen biaya, dan ini harus diperlakukan sebagai argumen dalam cara Anda menganggarkan dan menjadwalkan pekerjaan pengembangan.
Mengapa pengujian yang terburu-buru dan tanpa skrip dapat diprediksi gagal
Kegagalan QA paling umum yang saya lihat bukanlah "tidak ada pengujian yang dilakukan", melainkan "pengujian terjadi, namun secara informal, oleh orang yang sama yang membuat fitur tersebut, tepat sebelum tenggat waktu". Ini gagal dalam cara yang spesifik dan dapat diprediksi: pengembang sudah mengetahui bagaimana fitur tersebut seharusnya digunakan, sehingga mereka mengujinya sesuai cara mereka membuatnya, bukan dengan cara pelanggan yang bingung, tidak sabar, atau tidak biasa akan menggunakannya.
Pelanggan nyata melakukan hal-hal yang tidak diantisipasi oleh pengembang: mereka mengklik dua kali tombol kirim, mereka menggunakan browser yang belum pernah diuji, mereka memiliki koneksi lambat yang menghentikan permintaan di tengah jalan, mereka memasukkan nomor telepon dengan tanda hubung di dalamnya. Tidak ada satupun yang tertangkap oleh orang yang menulis kode yang menguji karyanya sendiri dengan cepat sebelum rilis. Hal ini tertangkap oleh seseorang yang mendekati fitur tersebut secara baru, dengan rencana pengujian tertulis yang mencakup kasus-kasus kecil yang membosankan dan tidak menarik yang tidak terpikirkan oleh siapa pun ketika mereka bersemangat tentang fitur yang berfungsi sama sekali.
Apa yang harus diminta pemilik dari vendor atau tim mana pun
Anda tidak perlu memahami kode untuk menuntut praktik QA yang baik. Anda perlu menanyakan tiga hal konkrit dan benar-benar memeriksa keberadaannya.1. Rencana pengujian tertulis untuk setiap rilis, bukan "kami mengujinya dan terlihat baik-baik saja". Rencana pengujian mencantumkan skenario spesifik yang diperiksa, termasuk kasus edge dan jalur kegagalan, bukan hanya alur utama. 2. Lingkungan pementasan yang terpisah dari produksi. Perubahan diuji di tempat yang bukan sistem langsung yang digunakan pelanggan Anda saat ini. Jika vendor Anda menguji langsung pada produksi, setiap perubahan merupakan eksperimen langsung pada pelanggan yang membayar. Saya telah menulis tentang hal ini secara lebih rinci di [Mengapa Bisnis Anda Membutuhkan Lingkungan Pementasan] (/blog/why-you-need-a-staging-environment), karena ini adalah salah satu perbaikan dengan leverage tertinggi dan biaya terendah yang tersedia untuk hampir semua perangkat lunak yang menjalankan bisnis. 3. Pemeriksaan regresi sebelum setiap rilis. Fitur baru yang merusak fitur lama yang sebelumnya berfungsi adalah salah satu cara paling umum bug menjangkau pelanggan. Pemeriksaan regresi berarti mengonfirmasi bahwa fitur yang berfungsi kemarin masih berfungsi saat ini, bukan hanya fitur baru saat ini yang berfungsi secara terpisah.
Jika vendor tidak dapat membuat rencana pengujian, tidak memiliki lingkungan pementasan, dan tidak dapat menjelaskan cara mereka memeriksa regresi, Anda tidak membeli jaminan kualitas, Anda membeli harapan.
Kualitas tidak dapat diperiksa pada akhirnya
Ada godaan, terutama di bawah tekanan tenggat waktu, untuk memperlakukan QA sebagai gerbang terakhir: buat fitur dengan cepat, lalu minta seseorang "memeriksanya" tepat sebelum diluncurkan. Ini memperlakukan kualitas sebagai sesuatu yang dapat Anda tingkatkan pada langkah terakhir, dan itu tidak berhasil, karena alasan yang sama Anda tidak dapat membuat kue yang dipanggang dengan buruk menjadi baik dengan mendekorasinya dengan baik. Jika pengujian hanya dilakukan di bagian paling akhir, di bawah tekanan waktu, tanpa ada waktu yang dianggarkan untuk benar-benar memperbaiki apa yang ditemukan, maka langkah "pemeriksaan" menjadi teater. Bug ditemukan, tenggat waktu tidak berubah, dan bug tetap dikirimkan.
QA yang sebenarnya harus dianggarkan ke dalam jadwal sejak awal, dengan kelonggaran yang cukup sehingga menemukan masalah nyata tiga hari sebelum peluncuran tidak secara otomatis berarti tetap mengirimkannya. Jika jadwal pengembangan Anda sepertinya tidak pernah memberikan ruang bagi QA untuk benar-benar mengubah tanggal rilis, itu berarti kualitas bukanlah sebuah gerbang, hanya formalitas.
Daftar periksa tingkat pemilik yang sederhana
| Pertanyaan untuk ditanyakan kepada tim atau vendor Anda | Jawaban bendera merah |
|---|---|
| Apakah ada rencana tes tertulis untuk rilis ini? | "Kami mengujinya, tidak apa-apa" |
| Apakah ada lingkungan pementasan? | "Kami uji pada produksi, lebih cepat" |
| Siapa yang mengujinya, selain orang yang membangunnya? | "Pengembang memeriksanya sendiri" |
| Apa yang terjadi jika bug terlambat ditemukan? | "Kami tetap mengirimkannya dan memperbaikinya setelahnya" |
Kesimpulannya
Bug menjangkau pelanggan karena pengujian dilakukan secara terburu-buru, informal, dan dilakukan oleh orang yang sama yang membuat fitur tersebut, tanpa lingkungan pementasan atau rencana tertulis untuk menangkap apa yang tidak dapat mereka lihat dalam karya mereka sendiri. Semua ini tidak mengharuskan Anda memahami kode. Hal ini mengharuskan Anda untuk meminta rencana pengujian, lingkungan pementasan, dan pemeriksaan regresi, dan memperhatikan ketika vendor tidak dapat memproduksi salah satu dari ketiganya. Kualitas dibangun selama proses, bukan diperiksa pada akhirnya, dan hal ini berlaku baik Anda menjalankan satu atau lima puluh produk.