DASAR-DASAR PENGUJIAN PERANGKAT LUNAK Pada pengujian perangkat lunak, pelaku RPL menciptakan sekumpulan kasus uji untuk diujikan kepada perangkat lunak. Proses ini lebih terkesan berusaha untuk “membongkar” perangkat lunak yang sudah dibangun. Proses pengujian merupakan tahapan dalam RPL.

SASARAN PENGUJIAN PERANGKAT LUNAK Pengujian adalah proses mengeksekusi program dengan tujuan khusus untuk menemukan kerusakan Kasus uji yang baik adalah yang memiliki tingkat kemungkinan tinggi untuk menemukan kerusakan yang belum ditemukan Pengujian dikatakan berhasil jika berhasil menemukan kerusakan yang belum ditemukan

Sasaran di atas sekaligus mengimplikasikan adanya perubahan cara pandang di mana sebelumnya dikatakan bahwa pengujian yang berhasil adalah pengujian yang tidak menemukan kesalahan. Jika pengujian sukses dilakukan, maka akan ditemukan kesalahan dalam perangkat lunak.

PRINSIP PENGUJIAN PERANGKAT LUNAK Semua pengujian harus dapat ditelusuri sampai ke kebutuhan pelanggan. Pengujian harus direncanakan lama sebelum pengujian dimulai. Prinsip Pareto berlaku untuk pengujian perangkat lunak. Prinsip Pareto mengimplikasikan bahwa 80% dari semua kesalahan yang ditemukan selama pengujian akan dapat ditelusuri sampai 20% dari modul program. Permasalahannya adalah bagaimana mengisolasi modul yang dicurigai dan mengujinya dengan teliti 22/3/SI6D

Pengujian harus mulai “dari yang kecil” dan berkembang ke pengujian “yang besar”. Pengujian pertama kali dilakukan fokus pada modul individual perangkat lunak, kemudian pengujian mengubah fokus menjadi menemukan kesalahan pada cluster modul yang terintegrasi, dan akhirnya pada sistem secara keseluruhan

Tidak mungkin melakukan pengujian yang mendalam Tidak mungkin melakukan pengujian yang mendalam. Jumlah jalur permutasi untuk program yang berukuran menengah sangat besar. Karena itulah, tidak mungkin untuk mengeksekusi setiap kombinasi jalur skema pengujian. Tetapi dimungkinkan untuk secara memadai mencakup logika program dan memastikan bahwa semua kondisi dalam rancangan prosedural telah diuji

Agar memperoleh pengujian yang paling efektif, pengujian harus dilakukan oleh pihak ketiga yang independen. Maksudnya, agar pengujian memiliki tingkat kemungkinan yang tinggi untuk menemukan kesalahan, maka pelaku RPL yang membuat sistem tersebut bukanlah orang yang paling tepat untuk melakukan semua pengujian bagi perangkat lunak

TESTABILITAS Testabilitas perangkat lunak adalah seberapa mudah sebuah perangkat lunak dapat diuji. Karena pengujian merupakan proses yang sangat sulit, perlu diketahui apa saja yang dapat dilakukan untuk membuatnya menjadi mudah. Salah satu caranya adalah dengan menyediakan checklist mengenai masalah-masalah desain yang mungkin, fitur, dan lain sebagainya yang dapat membantu untuk bernegosiasi dengan pemrogram

Checklist sebuah perangkat lunak untuk diuji: 1. Operabilitas. “Semakin baik dia bekerja, semakin efisien dia dapat diuji.” - Sistem memiliki sedikit bug (bug menambah analisis dan biaya pelaporan ke proses pengujian) - Tidak ada bug yang memblokir eksekusi program - Produk berubah pada tahapan fungsional (memungkinkan pengembangan dan pengujian secara simultan)

2. Observabilitas. “Apa yang Anda lihat adalah apa yang Anda uji 2. Observabilitas. “Apa yang Anda lihat adalah apa yang Anda uji.” - Output yang berbeda dihasilkan oleh masing-masing input - Status dan variabel sistem dapat diamati selama eksekusi - Status dan variabel sistem di masa lalu dapat diamati (mis. transaction log) - Semua faktor yang mempengaruhi output dapat diamati - Output yang salah dapat diidentifikasi dengan mudah - Kesalahan internal dapat dideteksi secara otomatis melalui mekanisme self-testing - Kesalahan internal dilaporkan secara otomatis - Source code dapat diakses

3. Kontrolabilitas. “Semakin baik perangkat lunak dapat dikontrol, semakin banyak pengujian yang dapat diotomatisasi dan dioptimalkan” - Semua output yang mungkin dapat dimunculkan melalui beberapa kombinasi input - Semua kode dapat dieksekusi melalui berbagai kombinasi input - Keadaan dan variabel perangkat lunak dan perangkat keras dapat dikontrol secara langsung oleh perekayasa pengujian - Format input dan output konsisten dan terstruktur - Pengujian dapat dispesifikasi, dioptimasi, dan diproduksi ulang dengan baik

4. Dekomposabilitas. “Dengan mengontrol ruang lingkup pengujian, kita dapat lebih cepat mengisolasi masalah dan melakukan pengujian kembali dengan lebih baik” - Sistem perangkat lunak dibangun dari modul-modul yang independen - Modul-modul perangkat lunak dapat diuji secara independen

5. Kesederhanaan. “Semakin sedikit yang perlu diuji, semakin cepat pengujiannya” - Kesederhanaan pengujian (contohnya kumpulan fitur adalah kebutuhan minimum untuk memenuhi persyaratan) - Kesederhanaan struktural (contohnya arsitektur dimodularisasi untuk membatasi propagasi kesalahan) - Kesederhanaan kode (contohnya sebuah standar pengkodean diadopsi untuk kemudahan inspeksi dan pemeliharaan)

6. Stabilitas. “Semakin sedikit perubahan, semakin sedikit gangguan dalam pengujian.” - Perubahan pada perangkat lunak jarang - Perubahan pada perangkat lunak dapat dikontrol - Perubahan pada perangkat lunak tidak membuat pengujian yang telah ada menjadi tidak valid - Perangkat lunak dapat pulih dengan baik dari kerusakan

7. Kemampuan untuk dapat dipahami 7. Kemampuan untuk dapat dipahami. “Semakin banyak informasi yang dimiliki, semakin baik pengujiannya” - Rancangan dapat dipahami dengan baik - Ketergantungan antara komponen internal, eksternal, dan yang dipakai bersama dapat dipahami dengan baik - Perubahan terhadap rancangan dikomunikasikan - Dokumen teknis dapat diakses secara cepat - Dokumen teknis diorganisasikan dengan baik - Dokumen teknis bersifat spesifik dan detail - Dokumen teknis bersifat akurat

PENGUJIAN YANG “BAIK” DAPAT DILIHAT DARI ATRIBUT-ATRIBUT BERIKUT: 1. Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan. Untuk mencapai hal ini, penguji harus memahami perangkat lunak dan berusaha mengembangkan gambaran mengenai bagaimana perangkat lunak dapat gagal. Kemudian kegagalan-kegagalan tersebut diselidiki

2. Pengujian yang baik tidak redundan 2. Pengujian yang baik tidak redundan. Waktu dan sumber daya yang tersedia untuk pengujian terbatas. Tidak ada gunanya melakukan pengujian dengan tujuan yang sama dengan pengujian yang telah dilakukan sebelumnya. Setiap pengujian harus memiliki tujuan yang berbeda

3. Pengujian yang baik seharusnya “jenis terbaik” 3. Pengujian yang baik seharusnya “jenis terbaik”. Untuk pengujian- pengujian yang memiliki tujuan serupa, batasan waktu dan sumber daya dapat menghalangi eksekusi kelompok pengujian tersebut. Pada kasus semacam ini, maka pengujian yang memiliki kemungkinan paling besar untuk mengungkap seluruh kesalahan yang harus digunakan

4. Pengujian yang baik tidak boleh terlalu sederhana atau terlalu kompleks. Meskipun kadang-kadang mungkin untuk menggabungkan serangkaian pengujian ke dalam satu kasus uji, namun secara umum masing-masing kasus uji harus dieksekusi secara terpisah

TERIMA KASIH