7 Prinsip Pengujian Software
Berikut adalah penjelasan tentang 7 prinsip dalam software testing, yang sering dijadikan pedoman dalam proses pengujian perangkat lunak:
1. Testing menunjukkan adanya kesalahan (Testing shows the presence of defects)
Prinsip ini menyatakan bahwa tujuan utama dari pengujian perangkat lunak adalah menemukan bug atau cacat (defect) dalam perangkat lunak, bukan untuk membuktikan bahwa perangkat lunak bebas dari bug. Pengujian hanya dapat menunjukkan bahwa ada kesalahan jika ditemukan, tetapi tidak dapat menjamin bahwa perangkat lunak sepenuhnya bebas dari kesalahan.
- Pengujian tidak bisa membuktikan bahwa perangkat lunak bebas dari kesalahan. Bahkan setelah pengujian ekstensif, ada kemungkinan masih terdapat bug yang belum ditemukan.
- Sebaliknya, pengujian dapat membantu mengungkap bug yang ada sehingga dapat diperbaiki sebelum perangkat lunak digunakan oleh pengguna.
Contoh Kasus
1. Pengujian Form Login
Skenario: Sebuah aplikasi memiliki form login dengan dua input: username dan password. Terdapat validasi bahwa password minimal harus terdiri dari 8 karakter.
- Langkah Uji:
- Masukkan username dengan nilai valid dan password kurang dari 8 karakter (misalnya, “12345”).
- Klik tombol “Login”.
-
Hasil Uji:
Sistem menampilkan error “Password harus terdiri dari minimal 8 karakter”.
Defect ditemukan: Sistem tidak menangani input password dengan kurang dari 8 karakter dengan baik (misalnya, jika pesan error salah atau terjadi crash). - Kesimpulan: Pengujian berhasil menunjukkan bahwa ada defect dalam validasi password.
2. Pengujian Aplikasi E-Commerce
Skenario: Aplikasi e-commerce memiliki fitur checkout yang menghitung total harga setelah diskon.
- Langkah Uji:
- Masukkan beberapa produk ke keranjang belanja.
- Terapkan kode diskon.
- Klik tombol “Checkout”.
- Hasil Uji:
Jika total harga setelah diskon salah hitung (misalnya diskon 20% dari $100 menghasilkan $90, tetapi sistem menunjukkan $85), ini menunjukkan adanya defect dalam logika perhitungan diskon.
Kesimpulan:
- Pengujian ini menunjukkan bahwa perangkat lunak memiliki cacat (contohnya validasi input atau perhitungan logika yang salah).
- Namun, walaupun bug-bug yang ditemukan telah diperbaiki, masih mungkin ada bug lain yang belum ditemukan. Inilah sebabnya pengujian tidak bisa menjamin perangkat lunak bebas dari bug, tetapi memastikan bahwa perangkat lunak semakin mendekati kualitas yang diinginkan.
2. Pengujian yang menyeluruh tidak mungkin dilakukan (Exhaustive testing is impossible)
Prinsip ini menyatakan bahwa tidak mungkin untuk menguji semua kombinasi input, jalur eksekusi, atau skenario dalam perangkat lunak secara menyeluruh karena keterbatasan waktu, sumber daya, dan kompleksitas sistem. Oleh karena itu, pengujian harus dilakukan secara selektif dengan memprioritaskan area yang paling penting atau berisiko tinggi.
Kenapa tidak mungkin?
- Perangkat lunak modern sering memiliki berjuta-juta kombinasi input dan kondisi.
- Pengujian yang menyeluruh memerlukan waktu dan sumber daya tak terbatas.
- Kombinasi tertentu mungkin sangat jarang terjadi di dunia nyata, sehingga pengujian pada semua kombinasi menjadi tidak efisien.
Solusi
- Gunakan teknik seleksi seperti risk-based testing, equivalence partitioning, atau boundary value analysis untuk mengidentifikasi area yang perlu diuji secara intensif.
- Fokus pada fungsi yang paling kritis atau yang paling sering digunakan oleh pengguna.
Contoh Kasus
1. Aplikasi Form Input
Sebuah form memiliki tiga input:
- Nama pengguna (maksimal 50 karakter),
- Umur (angka antara 0 dan 120),
- Alamat email (validasi format email).
Jika kita mencoba semua kemungkinan kombinasi input untuk pengujian:
- Nama pengguna: Semua kemungkinan kombinasi huruf, angka, dan simbol (misalnya: 50 karakter = 62^50 kombinasi).
- Umur: 121 kemungkinan (0 hingga 120).
- Alamat email: Variasi format yang tak terbatas.
Kesimpulan: Menguji semua kombinasi ini secara menyeluruh tidak mungkin dilakukan dalam waktu yang wajar. Sebagai gantinya:
- Gunakan equivalence partitioning untuk mengelompokkan input yang serupa (contohnya, nama valid dan nama invalid).
- Fokus pada batasan (contoh: nama tepat 50 karakter, umur 0, umur 120).
2. Pengujian Sistem ATM
Sistem ATM memiliki berbagai kombinasi skenario:
- Kartu valid vs kartu tidak valid.
- Input PIN benar vs salah.
- Jumlah penarikan lebih besar, lebih kecil, atau sama dengan saldo.
- Pilihan layanan (penarikan, transfer, cek saldo, dll.).
Jika semua kombinasi skenario diuji, hasilnya menjadi eksponensial karena setiap kemungkinan saling berkaitan.
Kesimpulan:
- Fokuskan pengujian pada skenario yang paling sering terjadi (penarikan dana, transfer antar bank).
- Prioritaskan pengujian pada kasus berisiko tinggi (misalnya, penarikan dana lebih besar dari saldo).
Kesimpulan:
- Pengujian yang menyeluruh itu tidak realistis, tetapi pendekatan yang terstruktur dan selektif memungkinkan pengujian yang efisien.
- Pengujian bertujuan untuk mengurangi risiko dan meningkatkan kepercayaan terhadap kualitas perangkat lunak, bukan untuk mencoba mencakup segalanya.
3. Pengujian dini menghemat waktu dan biaya (Early testing saves time and money)
Prinsip ini menyatakan bahwa pengujian perangkat lunak sebaiknya dimulai sedini mungkin dalam siklus pengembangan untuk mendeteksi dan memperbaiki cacat (defects) sejak tahap awal. Semakin awal bug ditemukan, semakin murah dan mudah untuk memperbaikinya, karena kesalahan yang dibiarkan hingga tahap akhir akan memerlukan lebih banyak sumber daya untuk diidentifikasi dan diperbaiki.
Penjelasan
- Mengapa penting?
- Bug yang ditemukan pada tahap awal (misalnya, saat perencanaan atau desain) lebih mudah diperbaiki karena belum memengaruhi modul lainnya.
- Bug yang ditemukan pada tahap akhir (seperti pengujian sistem atau produksi) bisa mengakibatkan biaya perbaikan yang tinggi karena memerlukan perubahan besar atau penundaan peluncuran.
- Pengujian dini membantu mengurangi risiko pengembangan yang mahal dan waktu proyek yang tidak efisien.
- Solusi:
- Terapkan pengujian pada tahap awal seperti validasi spesifikasi, desain, dan kode awal (unit testing).
- Gunakan teknik seperti static testing (review dokumen atau analisis kode statis) sebelum memulai pengujian dinamis.
Contoh Kasus
1. Kesalahan dalam Spesifikasi
Sebuah tim mengembangkan aplikasi manajemen keuangan. Pada tahap desain, ditemukan bahwa spesifikasi untuk menghitung bunga salah karena menggunakan rumus yang tidak sesuai. Jika:
- Ditemukan di tahap desain: Cukup perbaiki dokumen spesifikasi. Biaya rendah dan cepat diperbaiki.
- Ditemukan setelah implementasi: Kode yang sudah ditulis harus diubah, dan modul lain yang terkait perlu diperbarui.
- Ditemukan setelah peluncuran: Perlu waktu dan biaya tambahan untuk memperbaiki, melibatkan tim pengembangan, pengujian ulang, dan komunikasi ke pengguna.
2. Bug dalam Desain Antarmuka
Sebuah aplikasi e-commerce dirancang dengan antarmuka pengguna yang tidak intuitif, membuat pengguna kesulitan memahami proses checkout.
- Jika masalah ditemukan saat prototipe desain diuji dengan pengguna, perubahan hanya memerlukan penyesuaian pada wireframe atau desain grafis.
- Jika masalah ditemukan setelah aplikasi selesai dikembangkan, pengembang harus mengubah kode antarmuka, mengulang pengujian, dan memperbarui dokumentasi.
3. Kesalahan Validasi Input
Seorang pengembang melewatkan validasi input pengguna dalam modul login (contoh: tidak ada pemeriksaan untuk kata sandi kosong).
- Jika kesalahan ini ditemukan selama tahap unit testing oleh pengembang, perbaikan hanya membutuhkan penyesuaian kecil pada kode.
- Jika ditemukan saat pengujian sistem, integrasi, atau bahkan setelah peluncuran, biaya dan waktu tambahan diperlukan untuk mengidentifikasi dampaknya pada modul lain dan memperbaiki keseluruhan sistem.
Keuntungan Pengujian Dini
- Biaya Perbaikan Lebih Murah: Bug yang ditemukan di tahap awal lebih mudah diperbaiki karena perubahan hanya memengaruhi bagian kecil dari proyek.
- Mengurangi Risiko Penundaan: Menemukan dan memperbaiki bug dini mengurangi kemungkinan penundaan pada tahap akhir.
- Meningkatkan Kualitas: Dengan mendeteksi kesalahan sejak awal, tim dapat memastikan bahwa perangkat lunak dikembangkan di atas pondasi yang kuat.
Kesimpulan:
- Early testing saves time and money karena kesalahan yang ditemukan lebih awal dalam siklus pengembangan lebih murah dan mudah diperbaiki dibandingkan kesalahan yang ditemukan di tahap akhir.
- Pendekatan ini membantu tim memastikan bahwa perangkat lunak memenuhi kebutuhan sejak awal, meminimalkan risiko besar di tahap akhir pengembangan.
4. Kumulasi defect (Defects cluster together)
Prinsip ini menyatakan bahwa sebagian besar bug atau cacat perangkat lunak biasanya ditemukan di area tertentu dalam sistem, seperti modul, fitur, atau komponen tertentu. Fenomena ini sering mengikuti Hukum Pareto (80-20 Rule), di mana 80% bug ditemukan dalam 20% area tertentu.
Penjelasan
- Mengapa terjadi?
- Modul yang kompleks atau baru dikembangkan lebih rentan terhadap bug.
- Area yang sering diperbarui atau dimodifikasi cenderung memiliki lebih banyak kesalahan.
- Kesalahan desain atau implementasi pada satu bagian sering menghasilkan bug berantai.
- Solusi:
- Fokuskan pengujian pada area yang diketahui rentan atau memiliki banyak bug berdasarkan pengalaman sebelumnya.
- Gunakan data historis untuk mengidentifikasi area kritis (contoh: data bug report dari versi sebelumnya).
Contoh Kasus
1. Aplikasi E-Commerce
Sebuah aplikasi e-commerce memiliki beberapa fitur, seperti:
- Halaman Login
- Keranjang Belanja
- Proses Checkout
- Pembayaran
Dari pengujian sebelumnya, ditemukan bahwa:
- Sebagian besar bug ditemukan dalam modul Proses Checkout (contoh: salah hitung pajak, diskon, atau pengiriman).
- Modul ini memiliki logika yang rumit dan terhubung dengan banyak sistem eksternal (seperti gateway pembayaran dan inventaris).
Kesimpulan:
- Fokuskan pengujian lebih mendalam pada modul Proses Checkout, karena kemungkinan besar akan ditemukan lebih banyak bug di sana.
2. Sistem Banking
Sistem perbankan memiliki berbagai modul, seperti:
- Pengelolaan Rekening
- Transaksi Transfer
- Penarikan Uang di ATM
- Pelaporan dan Laporan Keuangan
Pengujian menunjukkan bahwa:
- Sebagian besar bug ditemukan di modul Transaksi Transfer, karena:
- Modul ini sering diperbarui untuk mendukung berbagai metode transfer (antar bank, internasional).
- Logika transfer rumit (misalnya, validasi rekening tujuan, biaya transaksi, atau batas transfer).
Kesimpulan:
- Modul Transaksi Transfer memerlukan pengujian lebih intensif, termasuk pengujian berbasis risiko.
Kesimpulan:
- Defects cluster together berarti pengujian harus difokuskan pada area yang diketahui rawan bug.
- Data historis atau analisis risiko dapat digunakan untuk menentukan area prioritas.
- Dengan prinsip ini, pengujian menjadi lebih efisien karena sumber daya difokuskan pada area yang paling mungkin bermasalah.
5. Paradoks pembasmi bug (The pesticide paradox)
Prinsip ini menyatakan bahwa jika pengujian yang sama dilakukan berulang kali, maka metode pengujian tersebut akan menjadi kurang efektif dalam menemukan bug baru. Seperti pestisida yang digunakan secara berulang terhadap tanaman, efektivitasnya menurun karena hama mulai kebal. Dalam konteks pengujian perangkat lunak, jika skenario pengujian yang sama digunakan terus-menerus, kemungkinan besar hanya akan menemukan bug yang sudah ada sebelumnya, sementara bug baru tetap tersembunyi.
Penjelasan
- Mengapa terjadi?
- Pengujian berulang cenderung hanya mencakup area yang sama.
- Bug baru sering muncul di area yang belum diuji atau dalam kondisi yang tidak terduga.
- Perubahan pada perangkat lunak dapat menciptakan skenario baru yang belum diuji.
- Solusi:
- Tinjau dan tingkatkan test cases secara berkala untuk mencakup area baru atau skenario yang belum diuji.
- Kombinasikan metode pengujian yang berbeda, seperti pengujian manual, otomatisasi, atau pengujian eksplorasi.
- Gunakan pendekatan berbasis risiko untuk fokus pada area yang rentan terhadap bug baru.
Contoh Kasus
1. Aplikasi Manajemen Keuangan
Sebuah aplikasi memiliki fitur untuk menghitung anggaran bulanan dengan formula tertentu. Pengujian awal menemukan bug dalam formula penghitungan dengan skenario berikut:
- Masukkan pendapatan: 10.000
- Masukkan pengeluaran: 8.000
- Hasilnya: Kesalahan pada penghitungan sisa anggaran.
Setelah bug diperbaiki, pengujian yang sama dilakukan berulang kali untuk memverifikasi perbaikan. Namun:
- Pengujian ini tidak mencakup skenario baru, seperti:
- Pendapatan atau pengeluaran dengan nilai nol.
- Angka desimal pada input.
- Input yang sangat besar atau sangat kecil.
Akibatnya, bug baru terkait skenario di atas tidak terdeteksi.
Solusi: Revisi dan tambahkan skenario pengujian untuk mencakup skenario baru seperti input desimal, nilai nol, atau angka besar.
2. Sistem Reservasi Tiket
Sistem memiliki fitur:
- Pencarian jadwal penerbangan.
- Pemesanan tiket.
- Pembayaran.
Pengujian awal berhasil menemukan bug pada fitur pembayaran kartu kredit. Setelah bug diperbaiki, pengujian dilakukan secara otomatis hanya untuk fitur ini. Namun:
- Bug pada fitur pencarian jadwal (misalnya, pencarian gagal untuk penerbangan internasional) tidak terdeteksi karena tidak diuji secara eksplorasi.
Solusi: Variasikan pengujian dengan menambahkan skenario baru untuk area yang jarang diuji, seperti pencarian penerbangan internasional.
Kesimpulan:
- The pesticide paradox menunjukkan bahwa pengujian harus terus berkembang untuk tetap efektif dalam menemukan bug baru.
- Penguji perlu mengubah, memperbarui, atau menambahkan test cases sesuai dengan perubahan perangkat lunak atau penemuan bug sebelumnya.
- Pendekatan ini memastikan cakupan pengujian yang lebih luas dan membantu meningkatkan kualitas perangkat lunak.
6. Pengujian tergantung pada konteks (Testing is context dependent)
Prinsip ini menyatakan bahwa pengujian perangkat lunak harus disesuaikan dengan konteks atau tujuan aplikasi. Metode, teknik, dan pendekatan pengujian yang digunakan akan bervariasi tergantung pada jenis perangkat lunak, industri, atau kebutuhan spesifik pengguna.
Penjelasan
- Mengapa penting?
- Setiap perangkat lunak memiliki karakteristik, risiko, dan kebutuhan pengguna yang berbeda.
- Pendekatan pengujian untuk aplikasi kritis (seperti perangkat medis atau sistem perbankan) akan berbeda dari aplikasi sederhana (seperti aplikasi game atau media sosial).
- Faktor seperti tingkat risiko, regulasi industri, dan kompleksitas perangkat lunak memengaruhi strategi pengujian.
- Solusi:
- Pahami jenis perangkat lunak dan lingkungan di mana perangkat lunak tersebut digunakan.
- Pilih teknik dan alat pengujian yang sesuai dengan konteks tersebut.
Contoh Kasus
1. Aplikasi Perbankan (High-Risk System)
Aplikasi perbankan memproses transaksi keuangan yang sensitif dan memiliki risiko tinggi, sehingga:
- Fokus Pengujian:
- Keamanan (security testing) untuk mencegah kebocoran data atau akses ilegal.
- Akurasi logika bisnis (misalnya, perhitungan bunga atau transfer uang).
- Ketahanan (stress testing) untuk memastikan sistem dapat menangani ribuan transaksi sekaligus.
- Pendekatan:
- Gunakan pengujian berbasis risiko dan kepatuhan terhadap standar industri (misalnya, PCI DSS).
2. Aplikasi Game Mobile (Entertainment System)
Aplikasi game mobile memiliki fokus berbeda dibandingkan aplikasi perbankan:
- Fokus Pengujian:
- Kinerja (performance testing) untuk memastikan game berjalan lancar di berbagai perangkat.
- Pengalaman pengguna (usability testing) untuk memastikan game menyenangkan dan intuitif.
- Kompatibilitas (compatibility testing) dengan berbagai sistem operasi dan perangkat.
- Pendekatan:
- Gunakan simulasi pengguna dan perangkat nyata untuk mengevaluasi pengalaman bermain.
3. Perangkat Lunak Medis (Safety-Critical System)
Perangkat lunak untuk alat medis, seperti monitor detak jantung:
- Fokus Pengujian:
- Keandalan (reliability testing) untuk memastikan sistem berfungsi dengan benar dalam kondisi kritis.
- Validasi terhadap standar regulasi (misalnya, FDA untuk perangkat medis).
- Respons waktu nyata (real-time testing) untuk memastikan hasil disampaikan secara instan.
- Pendekatan:
- Gunakan metode pengujian formal dengan dokumentasi yang lengkap.
4. Aplikasi E-Commerce
Aplikasi untuk belanja online memerlukan pendekatan yang berbeda:
- Fokus Pengujian:
- Fungsi bisnis utama (misalnya, pencarian produk, checkout, dan pembayaran).
- Ketahanan sistem selama periode puncak (misalnya, Black Friday).
- Keamanan untuk melindungi data pelanggan.
- Pendekatan:
- Pengujian beban (load testing) untuk menangani banyak pengguna secara bersamaan.
- Simulasi pembayaran melalui gateway pembayaran yang berbeda.
Kesimpulan
- Pengujian bergantung pada konteks: Setiap aplikasi memiliki tujuan, pengguna, dan risiko yang berbeda, sehingga pendekatan pengujian tidak bisa disamaratakan.
- Pahami kebutuhan bisnis, jenis perangkat lunak, dan ekspektasi pengguna untuk menentukan teknik pengujian yang paling efektif.
7. Absensi bug bukan jaminan kualitas (Absence of errors fallacy)
Prinsip ini menyatakan bahwa tidak adanya bug dalam perangkat lunak tidak menjamin bahwa perangkat lunak tersebut memenuhi kebutuhan pengguna atau mencapai tujuan bisnisnya. Dengan kata lain, meskipun semua pengujian menunjukkan bahwa perangkat lunak bebas dari kesalahan teknis, perangkat lunak tersebut tetap bisa gagal jika tidak sesuai dengan spesifikasi atau tidak memberikan nilai bagi pengguna.
Penjelasan
- Mengapa hal ini terjadi?
- Pengujian hanya menemukan dan memperbaiki bug teknis, tetapi tidak selalu memastikan bahwa perangkat lunak melakukan hal yang benar sesuai dengan kebutuhan pengguna.
- Perangkat lunak yang dirancang atau dikembangkan dengan spesifikasi yang salah akan tetap “gagal” meskipun bebas bug.
- Keberhasilan perangkat lunak tidak hanya ditentukan oleh ketepatan teknis, tetapi juga oleh kegunaannya dalam konteks pengguna.
- Solusi:
- Selain pengujian fungsional dan teknis, lakukan pengujian berbasis kebutuhan pengguna (user acceptance testing) untuk memastikan perangkat lunak sesuai dengan harapan pengguna.
- Validasi spesifikasi sejak awal untuk memastikan bahwa kebutuhan bisnis telah diterjemahkan dengan benar.
Contoh Kasus
1. Aplikasi Pemesanan Tiket
Sebuah aplikasi pemesanan tiket transportasi diuji dan ditemukan bebas dari bug:
- Tidak ada masalah dalam pencarian jadwal.
- Proses pemesanan tiket berjalan lancar.
- Pembayaran berhasil dilakukan.
Namun, setelah diluncurkan:
- Pengguna mengeluh karena aplikasi tidak memberikan opsi untuk memesan tiket pulang-pergi dalam satu transaksi, yang merupakan kebutuhan utama pengguna.
Kesimpulan:
Meskipun aplikasi bebas dari bug teknis, itu gagal memenuhi kebutuhan pengguna karena tidak dirancang untuk mendukung skenario utama (pulang-pergi).
2. Aplikasi Manajemen Proyek
Sebuah aplikasi manajemen proyek diuji:
- Semua fitur seperti membuat proyek, menambahkan anggota tim, dan melacak tugas bekerja dengan benar.
- Tidak ditemukan bug teknis.
Namun, setelah digunakan oleh tim:
- Pengguna menganggap antarmuka terlalu rumit.
- Fitur yang sering digunakan sulit ditemukan atau tidak intuitif.
Kesimpulan:
Aplikasi dianggap gagal meskipun secara teknis bebas dari bug, karena kegunaan (usability) tidak diperhatikan.
3. Sistem Perbankan
Sebuah bank meluncurkan sistem baru untuk mengelola transfer internasional. Sistem diuji dan semua transaksi berjalan lancar tanpa kesalahan teknis. Namun:
- Sistem hanya mendukung transfer dalam mata uang tertentu dan tidak mencakup mata uang yang banyak digunakan oleh pelanggan.
Kesimpulan:
Meskipun sistem bebas dari kesalahan teknis, itu tidak memenuhi kebutuhan pelanggan, yang menyebabkan penurunan kepuasan pengguna.
Kesimpulan:
- Absence of errors fallacy mengingatkan bahwa perangkat lunak yang bebas dari bug belum tentu “berhasil.”
- Keberhasilan perangkat lunak ditentukan oleh kemampuannya memenuhi kebutuhan pengguna dan tujuan bisnis, bukan hanya oleh ketepatan teknisnya.
- Pengujian harus mencakup validasi kebutuhan pengguna, pengalaman pengguna, dan dampak bisnis, selain pengujian teknis.