Memahami apa itu software reliability, mengapa QA penting, dan belajar dari insiden kegagalan perangkat lunak yang mengubah dunia.
Bayangkan Anda naik pesawat. Anda duduk tenang karena yakin pesawat itu tidak akan tiba-tiba mati mesin di udara. Keyakinan itu muncul karena pesawat tersebut dirancang untuk andal — diuji ribuan jam, bersertifikat, dan dipantau terus-menerus.
Sekarang bayangkan aplikasi mobile banking yang Anda gunakan setiap hari. Ketika Anda transfer uang Rp 10 juta, apakah Anda yakin uang itu akan sampai dengan benar? Itulah inti dari keandalan perangkat lunak — software yang bekerja dengan benar, kapan pun dibutuhkan, dalam kondisi apapun.
Keandalan perangkat lunak = Keandalan seorang karyawan terpercaya.
Karyawan yang andal adalah yang selalu datang tepat waktu, menyelesaikan pekerjaan dengan benar, tidak membuat kesalahan fatal, dan bisa diandalkan bahkan saat tekanan tinggi. Software yang andal bekerja persis sama!
Software Reliability adalah probabilitas bahwa perangkat lunak akan menjalankan fungsinya yang diinginkan tanpa kegagalan dalam jangka waktu tertentu, pada lingkungan yang telah ditentukan.
Reliability adalah kemampuan sistem atau komponen untuk melakukan fungsinya dalam kondisi yang ditetapkan selama periode waktu tertentu. ISO 25010 menjadikan Reliability sebagai salah satu dari 8 karakteristik kualitas utama.
Hardware itu seperti mesin cuci, software seperti resep masakan.
Mesin cuci bisa rusak karena aus — komponen fisiknya memburuk seiring waktu. Tapi resep masakan tidak bisa "aus". Resep itu salah dari awal atau benar dari awal. Kalau hasil masakannya buruk, bukan karena resepnya "tua" — tapi karena ada kesalahan dalam penulisannya, atau tidak cocok untuk kondisi tertentu (misalnya dapur di ketinggian tinggi).
| Aspek | Hardware | Software |
|---|---|---|
| Penyebab kegagalan | Keausan fisik, korosi, panas berlebih | Kesalahan desain/logika, input tak terduga |
| Pola kegagalan | Bathtub curve (tinggi awal, stabil, tinggi di akhir) | Tinggi di awal (banyak bug), menurun setelah patch |
| Diperbaiki dengan | Mengganti komponen fisik | Memodifikasi kode (patch/update) |
| Faktor lingkungan | Suhu, kelembaban, getaran | Input pengguna, beban sistem, konfigurasi |
| Salinan identik | Tidak — tiap unit bisa berbeda | Ya — semua salinan identik, bug sama semua |
Poin kritis: Berbeda dengan hardware, software tidak "aus" — ia gagal karena cacat desain yang sudah ada sejak awal namun baru muncul saat kondisi tertentu terpenuhi.
ISO/IEC 25010 mendefinisikan kualitas perangkat lunak dari 8 karakteristik utama. Dalam konteks kuliah ini, kita fokus pada 6 dimensi inti yang paling relevan:
Bayangkan sebuah restoran. Functionality = makanan yang dipesan benar-benar tersedia. Reliability = restoran tidak pernah tiba-tiba tutup saat jam makan siang. Usability = menu mudah dibaca dan dipahami. Efficiency = makanan datang cepat, tidak antri 2 jam. Maintainability = dapur mudah dibersihkan dan direnovasi. Portability = bisa buka cabang di kota lain dengan standar yang sama.
Kegagalan perangkat lunak bukan sekadar "error di layar". Dampaknya bisa berupa kerugian finansial triliunan rupiah, hilangnya nyawa manusia, atau guncangan sistem keuangan global. Berikut 3 kasus paling terkenal:
Apa yang terjadi? Therac-25 adalah mesin radioterapi kanker yang dikendalikan komputer. Antara 1985-1987, setidaknya 6 pasien menerima dosis radiasi 100 kali lebih besar dari yang seharusnya. Setidaknya 3 orang meninggal dunia.
Mengapa terjadi? Ada race condition — bug yang muncul hanya ketika operator mengetik perintah terlalu cepat dalam urutan tertentu. Kondisi ini jarang terjadi sehingga lolos dari pengujian. Tragisnya, software sebelumnya (Therac-20) memiliki pengaman hardware, tapi pengaman itu dihapus di versi baru karena pengembang "terlalu percaya" pada software.
Pelajaran:
Apa yang terjadi? Knight Capital Group, perusahaan trading saham Wall Street, mengaktifkan software trading otomatis baru. Dalam 45 menit, software membeli dan menjual saham secara erratik — menyebabkan kerugian USD 440 juta (±Rp 6 triliun). Perusahaan hampir bangkrut.
Mengapa terjadi? Saat deployment, satu server dari 8 server tidak mendapat versi software terbaru. Server lama masih menjalankan kode lama yang mengaktifkan fitur "Power Peg" — fitur debug yang harusnya sudah dinonaktifkan. Tidak ada monitoring real-time yang memadai, sehingga 45 menit berlalu sebelum siapapun menyadari ada yang salah.
Apa yang terjadi? Pada 19 Juli 2024, CrowdStrike — perusahaan keamanan siber terkemuka — mendorong update file konfigurasi sensor Falcon ke jutaan komputer Windows secara global. Akibatnya, 8,5 juta perangkat Windows mengalami Blue Screen of Death (BSOD) dan tidak bisa booting.
Dampak: Penerbangan dibatalkan di seluruh dunia (maskapai United, Delta, American Airlines lumpuh). Rumah sakit tidak bisa akses rekam medis. Bursa efek terganggu. Bank tidak bisa beroperasi normal. Pemerintahan kacau. Ini dianggap sebagai insiden IT terbesar dalam sejarah.
Mengapa terjadi? Update konfigurasi (bukan kode inti) dikirim tanpa melalui proses QA yang memadai — tidak ada staged rollout, tidak ada canary deployment, tidak ada rollback otomatis.
Kesimpulan dari ketiga kasus: Kegagalan software tidak harus disebabkan oleh programmer yang "bodoh". Therac-25 oleh insinyur berpengalaman, Knight Capital oleh tim profesional Wall Street, CrowdStrike oleh perusahaan keamanan siber top dunia. Kegagalan muncul karena proses QA yang tidak memadai.
Banyak yang mengira QA hanya berarti "cek software sebelum dirilis". Itu adalah pemahaman yang salah dan berbahaya. QA adalah proses yang berjalan sepanjang seluruh siklus hidup pengembangan software.
QA dalam software seperti inspeksi dalam membangun rumah. Anda tidak hanya memeriksa rumah setelah selesai dibangun — arsitek mengecek desain (QA di requirements), mandor mengecek fondasi (QA di design), inspektor mengecek konstruksi setiap hari (QA di development), dan baru terakhir ada pemeriksaan akhir (testing). Jika fondasi salah dan baru ditemukan setelah rumah jadi, biayanya jauh lebih mahal daripada menemukannya saat fondasi baru dibangun!
QA: Review dokumen persyaratan — apakah jelas, lengkap, tidak ambigu? Deteksi kebutuhan yang bertentangan sebelum coding dimulai.
QA: Review arsitektur, desain database, antarmuka — apakah desain memungkinkan sistem yang andal dan dapat diuji?
QA: Code review, static analysis, unit testing — cari dan perbaiki bug sejak baris kode pertama ditulis.
QA: Integration test, system test, performance test, user acceptance test — validasi sistem secara komprehensif.
QA: Verifikasi environment, staged rollout, monitoring — pastikan rilis tidak seperti CrowdStrike 2024!
QA: Regression testing saat ada update, monitoring keandalan sistem, analisis defect yang dilaporkan pengguna.
Proses pencegahan — memastikan proses pengembangan yang benar diikuti. SQA bersifat proaktif: "Bagaimana agar kita tidak membuat bug sejak awal?"
Aktivitas deteksi — menjalankan software untuk menemukan bug yang sudah ada. Testing bersifat reaktif: "Bug apa yang sudah ada di dalam sistem?"
Hasil akhir dari QA dan testing yang baik. Reliability adalah ukuran seberapa andal software bekerja di tangan pengguna nyata.
SQA yang baik → Testing yang efektif → Bug berkurang → Reliability meningkat. Ketiganya bekerja bersama, bukan menggantikan satu sama lain!
QA = Prosedur kebersihan pabrik yang ketat (mencegah kontaminasi). Testing = Quality control di akhir lini produksi (mengecek setiap produk). Reliability = Kepuasan pelanggan karena produk selalu enak dan aman dimakan. Pabrik terbaik melakukan ketiganya!
Fondasi & Metrik
Model & Strategi
Testing & Defect
Intro AI/ML
UTS
ML & AIOps
Cloud & Security
Masa Depan
Menjelaskan dan mengukur keandalan software dengan metrik standar
Merancang strategi QA berbasis risiko untuk proyek nyata
Mengimplementasikan ML untuk prediksi defect dan anomali
Membangun pipeline QA otomatis dalam ekosistem CI/CD
Menganalisis insiden kegagalan dan menemukan akar masalah
Mengevaluasi keandalan sistem microservices dan cloud
Jelaskan perbedaan utama antara reliability pada hardware dan software. Mengapa software yang sudah "jadi" bisa tiba-tiba gagal meskipun tidak ada perubahan apapun?
Pada kasus CrowdStrike 2024, proses QA apa saja yang seharusnya dilakukan sebelum mendistribusikan update ke 8,5 juta komputer? Jelaskan minimal 3 tahapan!
Anda adalah QA lead untuk aplikasi e-commerce baru. Jelaskan bagaimana Anda akan memastikan ke-6 dimensi kualitas ISO/IEC 25010 terpenuhi. Berikan contoh konkret untuk masing-masing dimensi!
Apa perbedaan antara Software QA, Software Testing, dan Software Reliability? Gambarkan hubungan ketiganya dengan analogi dari kehidupan sehari-hari!
Dari ketiga studi kasus (Therac-25, Knight Capital, CrowdStrike 2024), manakah yang menurut Anda memiliki dampak terbesar? Jelaskan alasan Anda dari perspektif sistem informasi!
Sumber: IEEE Std 610.12 dan ISO/IEC 25010
Inilah mengapa software memerlukan pendekatan QA yang berbeda dari hardware
Semua dimensi sama pentingnya, tidak bisa hanya fokus satu
Menemukan bug di requirements jauh lebih murah daripada menemukan setelah rilis
QA (proses) + Testing (deteksi) = Reliability (hasil)