Verivikasi dan Validasi Perangkat Lunak

Tugas

VERIVIKASI DAN VALIDASI PERANGKAT LUNAK

(Ringkasan Materi BAB 17)

       NIARMA     (E1E1 13 024)

PROGRAM STUDI S1-INFORMATIKA

FAKULTAS TEKNIK

UNIVERSITAS HALUOLEO

2016

STRATEGI PENGUJIAN PERANGKAT LUNAK

Sebuah perangkat lunak di uji untuk menemukan kesalahan yang ada saat pernagkat lunak tersebut di rancang dan di bangun. pengujian sering memerlukan usaha proyek yang lebih di banding kegiatan rekayasa perangkat lunak yang lain untuk menentukan apakah system yang dibangun sudah memenuhu syarat.

17.1 Pendekatan Strategis Dalam Pengujian Perangkat Lunak

Pengujian merupakan serangkaian kegiatan yang dapat di rencanakan di muka dan di lakukan secara sistematis.sebuah strategi untuk pengujian perangkat lunak harus mengkomodosi pengujian tingkat rendah  yang di perlukan untuk memveriikasi bahwa segmen kecil kode sumber telah di laksanakan dengan benar ,sebaik pengujian tingkat tinggi yang memvalidasi fungsi sistem utama terhadap persyaratan pelanggan.

17.1.1   Verivikasi dan Validasi

Pengujian perangkat lunak merupakan salah  satu elemen dari suatu topik yang lebih luas. Veriikasi merunjuk pada sekumpulan tugas yang memastikan bahwa perangkat lunak benar menerapkan  ungsi yang di tentukan .validasi merunjuk ke sekumpulan tugas yang berbeda yang memastikan bahwa perangkat lunak yang telah di bangun dapat di lacak berdas persyaratan pelanggan. Verifikasi dan validasi meliputi  beragam kegiatan SQA tinjauan teknis,audit,konigurasi, dan kualitas, monitoring kinerja, simulasi studi kelayakan ,kajian dokumentasi,tinjauan basis data, serta banyak kegiatan yang lain juga di perlukan.

17.1.2    Melakukan Pengujian Perangkat Lunak

Para pengembang perangkat lunak selalu bertanggung jawab untuk menguji masing-masing unit (komponen) dari program yang di kembangkannya,dan memastikan setiap komponen melakukan fungsi atau bekerja sesuai dengan apa yang telah di rancang. Peran dari kelompok pengujian idependen (idependent test group [ITG]) adalaah untuk menghapus masalah yang melekat sehubungan dengan membiarkan pembangun menguji apa yang telah di bangunya.pengujian idependen menghilangkan konflik kepentingan yang bisa saja ada.bagaimnapun,personel ITG di bayar untuk menemukan kesalahan.ITG adalah bagian dari tim proyek pengembangan perangkat lunak dalam arti ITG telibat selama analisis dan perancangan dan tetap terlibat (merencanakan dan menentukan prosedur pengujian) pada keseluruhan proyek besar.

17.1.3    Strategi  Pengujian Perangkat Lunak Gambaran Besar

Sistem rekayasa mendefinisikan peran perangkat lunak dan membaw kepada analisis persyaratan perangkat lunak, dimana domain informasi,fungsi,perilaku,kinerja,batasan dan kriteria validasi untuk perangkat lunak di tetapkan. Dengan bergerak ke arah dalam sepanjang spiral.Pengujian fokus pada masing-masing komponen secara individual dengan memastikan bahwa komponen tersebut berungsi secara tepat sebagain suatu unit.oleh karena itu di namakan mengujian unit.pengujian unit menggunakan teknik pengujian dengan menggunakan jalur  spesifik di dalam sebuah struktrul kontrol dari komponen untuk memastikan cakupan telah lengkap dan dapat mendeteksi kesalahn secara maksimum. Selanjutnya komponen ini  harus terpasang atau terintegrasi untuk membentuk paket perangkat lunak yang lengkap.pengujian integrasi  membahas isu-isu yang berkaitan dengan dua masalah yaitu verifikasi dan pembangunan program. Teknik-teknik perancangan kasus pengujian yang berfokus pada input dan output lebih lazim selama integrasi ,meskipun teknik-teknik tersebut menggunakan jalur program tertentu yang mungkin di gunakan untuk meastikan keseluruhan jalur kontrol untama.

17.1.4    Kriteria untuk Penyempurnaan Pengujian

Dengan mengumpulkan metrik selama proses pengujian perangkat lunak dan memanaatkan keandalan model perangkat lunak yang ada ,memungkinkan kita mengembangkan paduan yang bermanfaat dalam menjawab pertanyaan: kapan kita selesai melakukan pengujian?”Ada perdebatan kecil bahwa ada pekerjaan lebih lanjut yang perlu di lakukan sebelum aturan kuantitatif bagi pengujian di tetapkan,namun pendekatan empiris yang sekarang ini ada di anggap jauh lebih baik dari pada intuisi mentah.

17.2  Isu –Isu Strategis

      Untuk menentukan persyaratan produk secara kuantitas jauh sebelum pengujian dimulai.meskipun tujuan utama dari pengujian adalah untuk menemukan kesalahan,strategis pengujian yang baik juga menilai karakteristik kualitas yang lain seperti portabilitas,perawatan,dan kegunaan. Hal ini di tentukan dengan cara yang dapat di ukur sehingga hasil pengujiannya jelas. Nyatakan tujuan pengujian secara ekspilist.Tujuan khusus dari pengujian harus di nyatakan dalam istilah yang dapat di ukur. Memahami pengguna perangkat lunak dan mengembangkan sebuah profil untuk setiap kategori pengguna. Menggunakan kasus yang menggambarkan skenario interaksi untuk setiap kelompok pengguna dapat mengurangi usaha pengujian secara keseluruhan dengan berfokus pada pengujian penggunaan aktual produk yang di hasilkan. Membangun perangkat lunak yang “tangguh” serta untuk dapat menguji dirinya sendiri.Perangkat lunak harus di rancang dengan cra menggunakan teknik antibugging. Gunakan kajian teknis efektif sebagai filter sebelum pengujian .kajian dapat seefekti pengujian dalam upaya untuk mengungkap kesalahan.Melakukan kajian teknis untuk menilai strategi pengujian dan kasus pengujian kasus itu sendiri.kajian teknis dapat mengungkapkan ketidakkonsistenan,kelalaian, dan kesalahan langsung di dalam pendekatan pengujian.Hal ini menghemat wakktudan juga meningkatkan kualitas produk.Mengembangkan pedekatan perbaikan terus menerus untuk proses pengujian.

17.3  Strategi Pengujian Untuk Perangkat Lunak Konvensional

      Stategi pengujian yang di pilih oleh tim perangkat lunak ada di antara dua strategi yang ekstrem. Di butuhkan pandangan pengujian yang ekremental, di mulai dengan pengujian unit program secara individu ,kemudian bergerak ke pengujian yang di rancang untuk menasilitasi integrasi unit, dan mencapai puncaknya dengan pengujian yang menjalankan sistem yang dibangun.

17.3.1    Pengujian Unit

  Pengujian unit berokus pada upaya verifikasi terhadap unit terkecil dari perancangan perangkat lunak-komponen atau modul perangkat lunak. Pertimbangan-Pertimbangan dalam pengujian unit. Struktur data loka yang di periksa untuk memastikan inormasi yang benar mengalir kedalam dan keluar unit program yang sedang di uji. Pengujian selektif terhadap jalur eksekusi merupakan tugas penting selama pengujian unit .Pengujian batas merupakansalah satu tugas yang paling penting pada pengujian unit .perangkat lunak sering kali gagal pada batas-batasnya.Sebuah perancang yang baik mengantisipasi kondisi kesalahan dan menetpkan jalur penanganan kesalahan yang mngubah rute atau membersihkan proses yang berhenti ketika kesalahan terjadi.Prosedur pengujian unit. Pengujian unit biasanya di anggap sebagia tambahan dalam langkah penulisan kode program (coding). Perancangan pengujian unit dapat di lakukan sebelum penulisan kode program di mulai atau setelah program di hasilkan.Kajian atas informasi perancangan memberikan paduan untuk menetapkan kasus pengujian yang di gunakan untuk mengungkap kesalahan dalam setiap kategori .Karena  sebuah komponen bukanlah program yang berdiri sendiri,driver dan stub perangkat lunak harus sering di kembangkan untuk setiap pengujian unit.Driver dan stub merepresentasikan pengujian “overhead”.

17.3.2  Pengujian Integrasi

  Pengujian integrasi merupakan teknik sistematik untuk membangun arsitektur untuk perangkat lunak,sementara pada saat yang sama melakukan pengujian untuk menemukan kesalahan-kesalahan yang terkait denan atarmuka. Tujuannya adalah untuk mengambil komponen yang di uji dan membangun struktur program yang telah di tentukan oleh perancangan.Integrasi inkremental adlah antitesis dari pendekatan big bang. Integrasi atas-ke-bawah.Pengujian integrasi  atas-ke-bawah adalah pendekatan inkremental untuk membangun arsitektur perangkat lunak. Proses integrasi di lakukan dalam lima langkah berikut:

a)      Modul kendali utama di gunakan sebagai penguji driver dan stub di tambahkan pada semua modul yang secara langsung subordinat erhadap modul kontrol utama.

b)      Bergantung pada pendekatan integrasi yang di pilih (misalnya,depth-irst atau breadth first),stub subordinat di ganti pada suatu saat dengan komponen yang sesungguhnya.

c)      Pengujian di lakukan pada setiap komponen diintegrasikan.

d)     Setelah menyelesaikan setiap rangkaian pengujian,stub lain di gantikan dengan koponen yang sesungguhnya.

e)      Pengujian regresi (di bahas kemudian dalam bagian ini) dapat di lakukan untuk memastikan bahwa kesalahan baru belum di munculkan.

 Strategi aras-ke-bawah kedegaranya relati tidak rumit namun dalam praktiknya dapat muncul permasalahan logistik.Permaslahan ini kebanyakan terjadi saat di butuhkan pemrosesan di tingkat bawah hierarki agar pengujian di tingkat yang lebih tinggi memadai. memulai kontruksi dan pengujian dengan modul atomik (yakni, komponen-komponen di tingkat paling rendah dalam struktur program). Karena komponen-omponen tersebut diintegrasikan dari bawah ke atas fungsionalitas yang di sediakan oleh komponen subordinat ke tingkat tertentu selalu tersedia dari kebutuhan terhadap stub dapat dihilangkan. Strategi tersebut dapat di laksanakan dengan sebagai berikut:

a)       Komponen-komponen tingkat ke bawah di gabungkan ke dalam cluster-cluster (kadang-kadang di sebut membangun) yang menjalankan subunction perangkat lunak tertentu.

b)      Driver (program kontol untuk pengujian) di tulis dengan mengoordinasikan kasusu pengujian masukan dan keluaran.

c)      Cluster di uji

d)     Driver akan di hapus dan cluster di gabungkan dengan menggerakkanya ke atas di dalam struktur program.

Ketika integrasi bergerak ke atas, kebutuhan untuk memisahkan driver-driver penguji akan berkurang .Bahkan pada kenyataanya, jika kedua level teratas dari struktur program diintegrasikan atas-ke-bawah. Jumlah driver dapat di kurangi secara substansial dan integrasi terhadap cluster menjadii sangat sederhana. Pengujian regresi dapat di lakukan secara manual dengan mengeksekusi kembali subset dari semua kasus pengujian atau menggunakan peranti capture/playback otomatis.Sederatan pengujian regresi  berisi tiga kelas kasus pengujian yang berbeda-beda:

a)      Contoh representati dari pengujian yang akan menjalankann semua fungsi perangkat lunak.

b)      Tambahan pengujian yang berokus pada fungsi perangkat lunak yang mungkin di pengaruhi oleh perubahan yang terjadi.

c)      Pengujian yang berokus pada komponen-komponen perangkat lunak yang telah di ubah.

             Pada saat pengujian integrasi berlangsung ,jumlah pengujian regresi dapat berkembang menjadi sangat besar.Oleh karena itu ,perlu di rancang serangkaian pengujian regresi yang hanya memasukkan pengujian yang menekankan satu atau lebih kelas kesalahan dari setiap fungsi utama program.  Pengujian asap  ( smoke testing) adalah pendekatan   pengujian integrasi yang umumnya di gunakan ketika produk perangkat lunak di kembangkan. Pengujian asap ini di rancang sebagai mekanisme untuk proyek-proyek di waktu kritis, yang memunkinkan tim perangkat lunak menilai proyek seiring mungkin.Pendekatan pengujian-asap meliputi kegiatan berikut ini:

a)      Komponen-komponen perangkat lunak yang telah di terjemahkan ke dalam kode diintegrasikan ke dalam sebuah bangunan (build).

b)      Serangkaian pengujian ini di rancang untuk menyingkapkan kesalahan yang membuat bangunan tersebut tidak berungsi dengan semestinya.

c)      Bangunan ini di integrasikan denga banguna lainnya, dan seluruh produk (dalam bentuknya sekarang ini) di uji asap setiap hari.Pendekatan integrasi bisa menggunakan integrasi atas-ke-bawah atau bawah-ke-atas.

   Kerugian utama dari pendekatan atas-ke-bawah adalah kebutuhan akan stub dan kesulitan dalam menguji bantuan yang terkait dengan stub tersebut.

17.4  Strategi Pengujian Untuk Perangkat Lunak Beriorentasi Objek

Tujuan pengujian,yang dinyatakn secara sederhana,adalah untuk menemukan kemungkinan terbesar kesalahan dengan jumlah yang dapat di kelola dari usaha yang di terapkan dalam kurun waktu yang realistis.meskipun tujuan dasar ini tetap tidak berubah untuk perangkat lunak berorientasi objek.

 17.4.1   Pengujian Unit dalam Konteks OO

       Ketika perangkat lunak beriorentasi objek menjadi pertimbangan, maka konsep unitpun berubah. Enkapsulasi mengarhkan definisi kelas dan objek. Artinya, setiap kelas dan setiap instance dari sebuah kelas menunjukan atribut dan operasi yang memanipulasi data tersebut. Kelas yang terenkapsulasi biasanya merupakan fokus dari pengujian unit. Namun operasi (metode) dalam kelas tersebut adalah unit terkecil yang dapat di uji. Karena sebua kelas dapat berisi sejumlah operasi yang berbeda. Dan operasi tertentu mungin dad sebagai bagian dari jumlah kelas yang bereda. Maka taktik yang di terapkan untuk pengujian unit ini harus berubah. Pengujian kelas untuk perangkat lunak OO adalah setara dengan pengujian unit untuk perangkat lunak konvesional.Tidak seperti pengujian unit perangkat lunak konvensional,yang cenderung fokus pada detail algoritma dari sebuah modul dan data yang mengalir pada antar muka modul ,pengujian kelas untuk perangkat lunak OO di kendalikan oleh operasi-operasi yang dienkapsulasi oleh kelas tersebut dan oleh perilaku keadaan  kelas tersebut.

17.4.2    Pengujian Integrasi dalam Konteks OO

 Ada dua strategi yang berbeda untuk pengujian integrasi sistem OO .Strategi yang petama adalah pengujian berbasis thread,yang mngintegrasikan sekumpulan kelas yang di butuhkan untuk merespons satu masukan atau event ke dalam sistem.Setiap theread di integrasikan dan di uji secara individual.Pengujian regresi di terapkan untuk meastikan bahwa tidak ada eek samping yang terjadi. Pendekatan integrasi ke dua adalah pengujian berbasis kegunaan, yang memulai membangun sistem dengan menguji kelas-kelas tersebut yang menggunakan sangant sedikit kelas server. sampai.

17.5  Strategi Pengujian Untuk Aplikasi Web

Strategi untuk pengujian aplikasi web mengadopsi prinsip-prinsip dasar untuk semua pengujian perangkat lunak dan menerapkan strategi dan taktik yang di gunakan untuk sistem berorientasi objek. Langkah-langkah berikut ini:

a.       Model isi untuk aplikasi Web di tinjau untuk menemukan kesalahan

b.      Model antarmuka di tinjau untuk memastikan bahwa semua kasus yang digunakan dapat diakomodasi

c.       Model perancangan untuk aplikasi Web di tinjau untuk menemukan kesalahan navigasi

d.      Antarmuka pengguna diuji untuk menemukan kesalahan dalam presentasi dan/atau antarmuka

e.       Setiap komponen ungsional diterapkan pengujian-unit

f.       Navigasi seluruh arsitektur diuji

Banyak aplikasi Web berkembang terus-menerus ,karena itu proses pengujian juga di lakukan terus-menerus oleh staf  pendukung dengan menggunakan pengujian regresi yang berasal dari pengujian yang di kembangkan ketika aplikasi Web pertama kali di rekayasa.

17.6 Pengujian Validasi

Validasi dapat di definisikan dalam banyak cara, namun deinisinya yang sederhana adalah bahwa validasi berhasil jika perangkat lunak berungsi dengan cara yang di harapkan oleh pelanggan.

17.6.1                Kriteria Pengujian Validasi

Validasi perangkat lunak di capai melalui serangkaian pengujian yang memperlihatkan kesesuaian dengan persyaratan.Setelah setiap kasus pengujian validasi dilakukan di temukan salah satu dari dua kondisi berikut: Karakteristik fungsi atau kinerja sesuai dengan spesiikasi dan di terima dan penyimpanan dari spesifikasi di temukan dan daftar kelemahanya pun di buat.

17.6.2    Peninjauan Konigurasi

     Elemen penting dari proses validasi adalah peninjuan konigurasi .Tujauan adaya peninjauan ini adalah untuk memastikan bahwa semua elemen dari konfigurasi perangkat lunak telah secara benar di kembangkan ,di katalogkan dan memiliki rincian yang di perlukan untuk mendukung aktivitas pendukung.

17.6.1    Pengujian Alpa dan Beta

Pengujian alpha di lakukan disisi pengembangan oleh sekelompok perwakilan dari pengguna akhir.Pengujian alpha di lakukan dalam lingkungan yang di kendalikan. Pengujian beta di lakukan pada satu atau lebih pengguna akhir.Tidak seperti pengujian alpha ,pengembang biasanya tidak hadir. Oleh karena itu pengujian beta adalah aplikasi “hidup” dari perangkat lunak dalam sebuah lingkungan yang tidak dapat di kendalikan oleh pengembang.

17.7  Pengujian Sistem

     Masalah klasik dalam pengujian sistem adalah “saling menyalahkan” . Masalah ini terjadi ketika kesalahan tidak di temukan , dan pengembang dari elemen sistem yang berbeda saling menyalahkan karena masalah-masalah itu.Pengujian sistem adalah serangkaian pengujian yang berbeda-beda yang tujuan utamanya adalah untuk sepenuhnya mewujutkan sistem berbasis komputer.Meskipun masing-masing pengujian memiliki tujuan yang berbeda.

17.7.1    Pengujian Pemulihan

Pengujian pemulihan merupakan pengujian sistem yang memaksa perangkat lunak untuk gagal dalam berbagai cara dan memverifikasi bahwa pemulihan dilakukan dengan benar.Jika pemuliha tersebut otomatis (di lakukan oleh sistem itu sendiri), maka inisialisasi-kembali, mekanisme checkpointing,pemulihan data, dan restart dievaluasi untuk mengetahui apakah itu semua berjalan benar.

17.7.2    Pengujian Keamanan

Pengujian keamanan mencoba untuk menveriikasi mekanisme perlindungan yang di bangun ke dalam sistem yang pada kenyataanya ,melindunginya dari penetrasi yang tidak benar.

17.7.3    Pengujian Stres

  Yaitu pengujian yang menjalankan system dengan cara yang meminta umberdaya dengan jumlah , frekuensi dan volume yang abnormal. Sebuah variasi dari pengujian ini adalah teknik pengujian yang di sebut sensitivitas segelintir data dalam batas-batas data yang valid untuk sebuah program. Pengujian sensitivitas mencoba untuk menemukan kombinasi data dalam kelas input yang valid dapat menyebabkan ketidak stabilan atau pemrosesan yang tidak tepat.

17.7.4    Pengujian Kinerja

  Pengujian kinerja sering di gabungkan dengan pengujian stres dan biasanya memerlukan instrumentasi perangkat keras dan perangkat lunak.Artinya seringkali di perlukan untuk mengukur pemanaatan sumber daya dengan cara yang tepat. Dengan menginstrumentasi sistem, penguji dapat mengungkap situasi yang menyebapkan degradasi dan kegagalan sistem.

17.7.5    Pengujian Deployment

 Dalam banyak kasus , perangkat lunak harus di jalankan berbagai platrom dan berada di lebih dari satu lingkungan sistem operasi .Pengujian deployment ,kadang-kadang disebut pengujian konigurasi,menjalankan perangkat lunak di setiap lingkungan di mna perangkat lunak tersebut beroperasi.Pengujian deployment juga memeriksa semua prosedur instalasi dan perangkat lunak instalasi khusus yang akan di gunakan oleh pelanggan da semua dokumentasi yang akan digunakan untuk memperkenalkan perangkat lunak ke pengguna akhir.

17.8  Seni Pelacakan Kesalahan

     Pelacakan kesalahan terjadi sebagai akibat pengujian yang berhasil. Artinya , saat kasus pengujian mengungkap kesalahan ,debugging adalah proses yang menghasilkan penghapusan kesalahan.Meskipun pelacaan kesalahan dapat dan seharusnyan menjadi proses yang terurut, debugging masih sangat berbau seni.

17.8.1  Proses Pelacakan Kesalahan

    Pelacakan Kesalahan bukanlah pengujian , namun sering terjadi sebagai akibat dari pengujian.Proses pelacakan kesalahan di mulai dengan melakukan test case.Hasilnya kemudian dinilai dan di temukanlah ketidaksesuaian antara kinerja yang di harapkan dan kinerja yang sesungguhnya.Beberapa karakteristik kesalahan menyediakan beberapa petunujuk:

a)      Gejala dan penyebapnya mungkin secara geograis jauh

b)      Gejala mungkin hilang saat kesalahan lain di koreksi

c)      Gejala ini sebenarnya dapat di sebapkan oleh nonerrors (misalnya ketidakakuratan round-off)

d)     Gejala dapat di sebapkan oeleh kesalahan manusia yang tidak mudah untuk dilacak

e)      Gejala mungkin akibat dari masalah waktu dari pada akibat maslah pemrosesan

f)       Mungkin sulit untuk secara akurat memproduksi kondisi masukan (misalnya, aplikasi real-time dimna urutan masukan adalaah tak tentu)

g)      Gejala dapat berselang

h)      Gejala mungkin di karenakan penyebap yang distribusikan ke sejumlah tugas berjalan pada prosesor yang berbeda

Selama pelacakan kesalahan (debugging) akan menemukan kesalahan yang berkisar dari agak mengganggu (misalnya ormat keluaran yang salah). Sebagai konsekuensi dari peningkatan kesalahan ,jumlah tekanan untuk menemukan penyebapnya juga meningkat.

17.8.2    Pertimbangan Psikologis

adalah salah satu bagian yang lebih membuat rustasi di banding pemrograman.Debugging memiliki unsur-unsur pemecahan masalah atau permainan asah otak, di tambah dengan pengakuan menjengklkan bahwa telah membuat kesalahan .

17.8.3    Strategi Pelacakan Kesalahan

Secara umum ada tiga strategi pelacakan kesalahan (debugging) yang telah diusulkan 1, brute foce 2, backtracking 3, cause elimination.Tactick debugging . Metode debug brute force adalah metode palin eisien untuk mngisolasi penyebap kesalahan perangkat lunak.Barcktracking adalah pendekatan debugging yang mumum yang berhasil di gunakan di program-[rogram kecil.Mulai de tempat di mana gejala telah di temukan , kode program kemudian di lacak kebelakang (secara manual) sampai penyebapnya di temukan.Pendekatan debugging-menyingkirkan penyebap-ditunjuka oleh induksi atau deduksi dan memperkenalkan konsep partisi biner. Data yang terkait dengan terjadinya kesalahan di kelola untuk mengisolasi penyebap potensial.Pelacakan kesalahan (debugging) otomais.

17.8.4    Memperbaiki Kesalahan

Setelah kesalah ditemukan,maka kesalahan tersebut harus di koreksi.Namun, seperti yang telah kita catat , koreksi kesalahan  dapat memperkenalkan keslahan lain dan karena itu lebih berbahya daripada kebaikan yang di peroleh apabila kita mengerjakannya.

a)      Apakah penyebap bug dibuat ulang di bagian lain dari program ini? Dalam banyak situasi,sebuah cacat program (defect) disebapkan oleh pola logis yang salh yang mungkin di hasilkan ulang di tempat lain.

b)      Apakah “bug selanjutnya” dapat terjadi akibat perbaikan yang saya sedang buat? Sebelum koreksi di buat kode program (atau lebih baik,perancangan) harus devaluasi untuk menilai logika dan struktur data.

c)      Apa yang bisa kita lakukan untuk mencegah bug ini di tempat pertama? Pertanyaan ini adalah langkah pertam menuju pembangunan sebuah pendekatan jaminan kualitas perangkat lunak statistik.