• Tidak ada hasil yang ditemukan

dengan Testing dan Defects

Dalam dokumen Testing Dan Implementasi Sistem (Halaman 34-42)

Berikut ini akan dijabarkan biaya-biaya yang berkaitan dengan testing dan defects, serta penyeimbangan biaya-biaya tersebut.

2.11.1 Biaya-biaya testing

Biaya-biaya yang berkaitan dengan testing dapat dilihat sebagaimana terdapat pada tabel, di bawah ini.

Biaya Pencegahan Defects Biaya Penialaian dan Evaluasi Defects

Pelatihan staf Review disain

Analisa kebutuhan Inspeksi kode

Pembuatan protipe awal Glass-box testing Disain fault-tolerant Black-box testing Defensive programming Pelatihan tester

Analisa kegunaan Beta testing

Spesifikasi yang jelas Otomatisasi tes Dokumentasi internal yang akurat Usability testing Evaluasi terhadap reliabilitas dari alat

bantu pengembangan (sebelum membelinya) atau komponen lain dari produk yang potensial.

Pre-release out-box testing oleh staf customer service

Kebanyakan atribut biaya testing menghabiskan sekitar 25 % dari pengembangan. Beberapa proyek bahkan dapat mencapai sekitar 80% dari dana pengembangan (berdasarkan alasan yang dijabarkan dibawah ini).

2.11.2 Biaya-biaya defects

Terutama bagi pengembang software, biaya-biaya defects dapat berupa hal-hal sebagai berikut:

Kesiapan dukungan teknisi. Persiapan buku panduan FAQ. Investigasi komplain pelanggan.

Ganti rugi dan mengambil kembali produk. Coding atau testing dari pembenahan bugs. Pengiriman dari produk yang telah diperbaiki.

Penambahan biaya terhadap dukungan berbagai versi dari produk yang telah di release. Tugas Public Relation untuk menjelaskan review dari defects.

Bab II Dasar – Dasar Testing Halaman 25 Hilangnya kepercayaan pelanggan.

Pemberian potongan harga pada penjual agar mereka tetap menjual produk. Garansi.

Kewajiban.

Investigasi pemerintah. Pinalti.

Dan biaya lain yang berkaitan dengan hukum.

Biaya biaya Internal Biaya-biaya Eksternal

Pembenahan bugs Terbuangnya waktu

Regression Testing Hilangnya data Terbuangnya waktu in-house user Kerugian bisnis

Terbuangnya waktu tester Tercorengnya nama baik

Terbuangnya waktu penulis Keluarnya karyawan akibat frustasi Terbuangnya waktu pemasaran Hilangnya potesial presentasi

Terbuangnya promosi Kegagalan pelanggan karena software Biaya langsung dari keterlambatan

pengiriman

Terjadinya Failure dari tugas-tugas yang hanya dapat dilakukan sekali

Biaya atas hilangnya kesempatan akibat keterlambatan pengiriman

Biaya penggantian produk Biaya rekonfigurasi sistem

Biaya pembenahan software

Biaya dukungan teknisi Kecelakaan atau kematian

Dari riset biaya BOEHM [BOE76A] menyatakan bahwa untuk suatu komputer angkatan udara:

Biaya pengembangan software awal sebesar $75 perinstruksi Biaya perawatan sebesar $4000 perinstruksi

Menurut studi dari Martin dan MC Clure [MAR83a] menyimpulkan bahwa biaya-biaya relatif ditiap tahap pengembangan, seperti yang terlihat pada grafik dibawah ini :

Bab II Dasar – Dasar Testing Halaman 26

Gambar 2.3 Biaya relatif pada tiap tahap pengembangan

Pada studi ini, testing terhitung sebesar 45% dari biaya pengembangan awal. Testing juga merupakan bagian integrasi dari perawatan juga namun pada bahasan ini tidak dibedakan secara khusus.

2.11.3 Penyeimbangan Biaya

Feigenbaum (1991) mengestimasi biaya tiap kualitas untuk pencegahan (prevention) pada perusahaan umumnya menghabiskan biaya $0.05 sampai $0.1, sedangkan untuk evaluasi penilaian (appraisal) sebesar $0.2 samapa $0.25 dan sisanya $0.65 sampai $0.75 untuk biaya dari failure internal dan eksternal.

Gambar 2.4 Alokasi biaya (dalam dolar) kualitas secara umum.

Kebutuhan untuk menyeimbangkan biaya, sehingga besar pengeluaran tidak berada pada failure internal atau eksternal sangat dibutuhkan. Caranya dengan membandingkan biaya menghilangkan dalam kaitannya dengan perbaikan defect pada sistem secara keseluruhan. Akan sangat mahal untuk melakukan tes defect daripada mengkoreksinya, karenanya testing perlu di sederhanakan – biasanya dengan menerapkan testing untuk bagian yang penting sebelum menjadi masalah.

Bab II Dasar – Dasar Testing Halaman 27 Defect diasumsikan selalu berkaitan dengan adanya biaya perbaikan, karenanya total biaya perbaikan defect meningkat secara linier terhadap jumlah defect yang ada pada sistem. Sedangkan usaha testing akan meningkat secara eksponensial sesuai dengan meningkatnya proporsi defect yang diperbaiki. Hal ini menguatkan pandangan bahwa menghilangkan defect secara seratus persen adalah tidak mungkin, sehingga testing komplit juga tidak bisa dilakukan (sebagaimana telah didiskusikan pada prinsip satu dari testing diatas).

Gambar 2.5 Grafik hubungan usa testing terhadap biaya failure.

Grafik diata aman dan

estimasi, atau pengukuran internal dan analisa data.

Semakin tinggi tingkat kritis suatu proyek, biaya defect juga meningkat. Hal ini mengindikasikan banyak sumber daya dapat dialokasikan untuk mencapai proporsi penghilangan defect yang lebih tinggi. Seperti gambar dibawah ini:

ha

s dapat dikorelasikan terhadap alokasi biaya, berdasar pada pengal

Bab II Dasar – Dasar Testing Halaman 28

2.12 Siklus Hidup Software secara

Umum

Gambar 2.7 Model siklus hidup software

Metodologi merupakan sekumpulan tahap atau tugas. Kebanyakan organisasi menggunakan suatu standar untuk pengembangan software yang mendefinisikan suatu model siklus hidup (life cycle model), dan dibutuhkan tahap-tahap atau metodologi dalam pelaksanaannya. Ide pembagian dalam bentuk fase / tahapan digunakan pada semua metodologi software, dimana tiap fase mempunyai produk akhir yang merupakan serahan dan menjadi pertanda penyelesaian proses di tiap fase tersebut.

Pembagian fase-fase ini dapat tidak sama antar satu organisasi dengan organisasi yang lain, namun semuanya memiliki tahap-tahap dasar yang sama, yaitu Analisa, Disain, Implementasi dan Perawatan, sebagaimana terlihat pada gambar 2.7.

Bab II Dasar – Dasar Testing Halaman 29

2.13 Siklus Hidup Testing secara

Umum

Gambar 2.8 Siklus hidup testing

Tahapan untuk testing merupakan suatu komponen dari keseluruhan metodologi. Pada prakteknya, testing sangat kurang didiskripsikan dan telah dengan cepat bergerak ke titik dimana kebanyakan prosedur testing organisasi sudah ketinggalan jaman dan tidak efektif. Pada awalnya testing merupakan salah satu sub-fase dari fase pengembangan (development), setelah fase coding. Sistem didisain, dibangun dan kemudian dites dan didebug. Sejalan dengan kemapanan testing secara praktis, secara bertahap kita berpendapat bahwa sudut pandang testing yang tepat adalah dengan menyediakan suatu siklus hidup testing secara lengkap, yang merupakan suatu bagian dan menjadi satu kesatuan di dalam siklus hidup software secara keseluruhan, sebagaimana terlihat pada gambar 2.8.

2.14 Aktifitas Testing secara Umum

Apabila kita menggali lagi lebih dalam dari siklus hidup testing, tentang aktifitas apa saja yang terjadi di dalamnya, secara umum dan sederhana terdiri dari:

Perencanaan

Rencana pendekatan umum Menentukan obyektivitas testing Memperjelas rencana umum Akusisi

Disain tes Menerapkan tes

Bab II Dasar – Dasar Testing Halaman 30 Pengukuran

Eksekusi tes Cek terminasi Evaluasi hasil

2.15 Tiga Tingkatan Testing secara

Umum

Sedangkan macam atau tipe testing secara umum ada tiga macam, dimana bila kita sebutkan secara urut berdasarkan waktu penggunaannya, adalah sebagai berikut:

Unit testing

Testing penulisan kode-kode program dalam satuan unit terkecil secara individual. System Testing

Proses testing pada sistem terintegrasi untuk melakukan verifikasi bahwa sistem telah sesuai spesifikasi.

Acceptance Testing

Testing formal yang dilakukan untuk menentukan apakah sistem telah memenuhi kriteria penerimaan dan memberdayakan pelanggan untuk menentukan apakah sistem dapat diterima atau tidak.

2.15.1 Praktik unit testing secara umum

Tujuan

Konfirmasi bahwa modul telah dikode dengan benar. Pelaku

Biasanya programer. Apa yang dites

Fungsi (Black Box). Kode (White Box).

Kondisi ekstrim dan batasan-batasan. Kapan selesai

Biasanya saat programer telah merasa puas dan tidak diketahui lagi kesalahan. Alat bantu

Tidak biasa digunakan. Data

Biasanya tidak didata.

2.15.2 Praktik system testing secara umum

Tujuan

Merakit modul menjadi suatu sistem yang bekerja. Dan menentukan kesiapan untuk melakukan Acceptance Test.

Bab II Dasar – Dasar Testing Halaman 31 Pelaku

Pemimpin tim atau grup tes. Apa yang dites

Kebutuhan dan fungsi sistem. Antarmuka sistem.

Kapan selesai

Biasanya bila mayoritas kebutuhan telah sesuai dan tidak ada kesalahan mayor yang ditemukan.

Alat bantu

Sistem pustaka dan pustaka test case.

Generator, komparator dan simulator data testing. Data

Data kesalahan yang ditemukan. Test case.

2.15.3 Praktik acceptance testing secara umum

Tujuan

Mengevaluasi kesiapan untuk digunakan. Pelaku

Pengguna akhir atau agen. Apa yang dites

Fungsi mayor. Dokumentasi. Prosedur. Kapan selesai

Biasanya bila pengguna telah merasa puas atau tes berjalan dengan lancar / sukses. Alat bantu

Komparator. Data

Dalam dokumen Testing Dan Implementasi Sistem (Halaman 34-42)