Deffect

Software
*berbagai sumber
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.
M. Dan biaya lain yang berkaitan dengan hukum.
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.
Seperti gambar disamping ini:
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,
Implementasi dan Perawatan, sebagaimana terlihat pada gambar .
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 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.
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
- Biasanya tidak ada data
Praktik 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 yg di Tes
- Kebutuhan dan fungsi sistem.
- Antarmuka System
* Kapan selesai
Praktik Testing Secara Umum
- 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
Pratik Sistem Testing Secara Umum
* Tujuan
- Mengevaluasi kesiapan untuk digunakan.
* Pelaku
- Pengguna akhir atau agen .
* Apa yg di Tes
- Fungsi mayor.
- Dokumentasi.
- Prosedur.
* Kapan selesai
Pratik Acceptance Testing Secara
Umum
- Biasanya bila pengguna telah merasa puas atau tes berjalan dengan
lancar / sukses.
* Alat bantu
- Komparator.
* Data
- Formalitas dokumen