By Hendranet

2.11 Biaya-Biaya yang Berkaitan dengan Testing dan Defects

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 Pre-release out-box testing oleh staf customer bantu pengembangan (sebelum

service

membelinya) atau komponen lain dari By Hendranet

produk yang potensial.

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 . Hilangnya pangsa jual.

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

Terjadinya Failure dari tugas-tugas yang

pengiriman

hanya dapat dilakukan sekali

Biaya atas hilangnya kesempatan akibat

Biaya penggantian produk

keterlambatan pengiriman

Biaya rekonfigurasi sistem

Biaya pembenahan software By Hendranet

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 :

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.

By Hendranet

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.

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 ha testing terhadap biaya failure.

Grafik diata s dapat dikorelasikan terhadap alokasi biaya, berdasar pada pengal aman dan

estimasi, atau pengukuran internal dan analisa data. By Hendranet

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:

Gambar 2.6 Grafik hubungan usaha testing terhadap variasi biaya failure.

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, By Hendranet

namun semuanya memiliki tahap-tahap dasar yang sama, yaitu Analisa, Disain, Implementasi dan Perawatan, sebagaimana terlihat pada gambar 2.7.

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. By Hendranet

Pada awalnya testing merupakan salah satu sub-fase dari fase pengembangan ( development ), setelah fase coding . Sistem didisain, dibangun dan kemudian dites dan di debug . 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

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. By Hendranet

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 .

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.

By Hendranet

Prosedur. Kapan selesai Biasanya bila pengguna telah merasa puas atau tes berjalan dengan lancar / sukses. Alat bantu Komparator. Data Formalitas dokumen.