Deffect
Software
Pengertian Deffect Software
Kerusakan/Cacat perangkat lunak (software defect) didefinisikan sebagai
defect pada perangkat lunak yang mungkin terjadi defect pada kode
program, defect pada dokumentasi, pada desain, dan hal-hal lain yang
menyebabkan kegagalan perangkat lunak.
Software defect / bug adalah suatu kondisi dalam produk perangkat lunak
yang tidak memenuhi persyaratan perangkat lunak (sebagaimana tercantum
dalam spesifikasi persyaratan) atau harapan pengguna akhir (yang mungkin
tidak ditentukan tetapi masuk akal). Dengan kata lain, cacat adalah kesalahan
dalam pengkodean atau logika yang menyebabkan program tidak berfungsi
atau menghasilkan hasil yang salah / tidak diharapkan.
Kategori Deffect Software
Terdapat 13 kategori defect software (Kaner,Falk,Nguyen[KAM93A]):1. User Interface error-sistem memberikan suatu tampilan yang berbeda dari spesifikasi 2. Erroe handling- perlakuan terhadap error bila terjadi
3. Boundary- related error- perlakukan terdapat nilai batasan dari jangkauan mereka yang tidak benar
4. Calculation error – perhitungan aritmatika dan logika yang mungkin tidak benar 5. Initial and Later states – fungsi gagal pada saat pertama digunakan atau sesudah itu
6. Control flow error – pilihan terhadap apa yang dilakukan berikutnya tidak sesuai untuk status saat ini.
7. Error in handling or interpreting data – melewatkan dan mengkonversikan data antar sistem
Kategori Deffect Software
8. Race condition – bila dua event diproses maka salah satu akan diterima berdasarkan prioritas sampai pekerjaan selesai dengan baik, baru pekerjaan berikutnya.
9. Load condition – saat sistem dipaksa maksimum, amsalh akan mulai muncul, seperti arrays, overflow, diskfull.
10. Hardaware –antar muka dengan suatu device mungkin tidak dapat beroperasi dengan benar.
11. Source and Version Control – program yang telah kadarluarsa mungkin dapat digunakan lagi bila ada revisi.
12. Documentasi- penggunaan tidak dapat melihat operasi yang telah dideskripsikan dalam dokumen panduan
13. Tetsing error-tester membuat kesalahan selama testing dan berpikir bahawa sistem berkelakukan tidak benar.
Biaya-biaya Deffect
Terutama bagi pengembang software, biaya-biaya defects dapat berupa hal-hal sebagai
berikut:
A. Kesiapan dukungan teknisi.
B. Persiapan buku panduan FAQ.
C. Investigasi komplain pelanggan
D. Ganti rugi dan mengambilkembali produk.
E. Coding atau testing daripembenahan bugs.
F. Pengiriman dari produk yang telah diperbaiki.
G. Penambahan biaya terhadap dukungan berbagai versi dari produk yang telah di
release.
Biaya-biaya Deffect
H. Tugas Public Relation untuk menjelaskan review dari Defects.
I. Hilangnya pangsa jual.
J. Hilangnya kepercayaan pelanggan.
K. Pemberian potongan harga pada penjual agar mereka tetap
menjual produk.
L. Investigasi pemerintah.
Penyeimbang Biaya
Feigenbaum (1991) mengestimasi biaya
tiap kualitas untuk pencegahan (pre
vention) pada perusahaan umumnya
menghabiskan biaya $0.05 sampai $0.1,
sedangkan untuk evaluasi penilaian
(appraisal) sebesar $0.2 sampai $0.25 dan
sisanya $0.65 sampai $0.75 untuk biaya
dari failure internal dan eksternal.
Penyeimbang Biaya
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.
Penyeimbang Biaya
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.
Penyeimbang Biaya
Grafik diatas 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.
Siklus Hidup Software secaraUmum
Metodologi merupakan sekumpulan tahap atau tugas. Kebanyakan organisasi menggunakan suatu standar untuk pengembangan software yang men definisikan suatu model siklus hidup (life cycle model), dan dibutuhkan tahap-tahap atau metodolo gi dalam pelaksanaannya. Ide pembagian dalam bentuk fase / tahapan digunakan pada semua
metodologi software, dimana tiap fase mempunyai produk akhir yang merupakan serahan dan menja di pertanda penyelesaian proses di tiap fase terse
but. 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,
Siklus dan Aktifitas Testing
Apa itu Testing? Testing adalah pengujian Sebuah Aplikasi yang secara lengkap dan sudah saling terintegrasi. Biasanya sebuah software berbasis komputer saling terhubung, baik dari software (code,editor) sampai dengan hardware (Server, Jaringan Network, dll)
System Testing Intinya adalah mengetes sebuah aplikasi dari awal sampai akhir sehingga alur sistem dari aplikasi tersebut dapat diuji sehingga user dapat menikmati aplikasi tersebut dengan nyaman.
Berikut adalah Tujuan dari System Testing:
1. Menguji apakah aplikasi terintegrasi, menguji bagaimana komponen
berinteraksi satu sama lain dan dengan sistem secara keseluruhan. Ini juga disebut End to End pengujian skenario
2. Verifikasi pengujian menyeluruh dari setiap input dalam aplikasi untuk memeriksa output yang diinginkan.
3. Menguji User Experience / pengalaman user dalam mengunakan aplikasi tersebut.
Siklus Hidup Software secaraUmum
Tahapan untuk testing merupakan suatu komponendari 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.
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:
* PERENCAAN
- Rencana pendekatan Umum - Menentukan objektivitas testing - Memperjelas rencana umum * AKUSISI - Desain tes - Menerapkan tes * PENGUKURAN - Eksekusi tes - Cek terminal - Evaluasi hasil
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 .
Praktik Testing Secara Umum
* Tujuan
- Konfirmasi bahwa modul telah dikode dengan benar.
* Pelaku
- Biasanya programmer.
* Apa yang di Tes
- 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 bisa dibantu.
* Data
