DeffectSoftware*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 SoftwareTerdapat 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 DeffectTerutama 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 BiayaFeigenbaum (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 sampai $0.25 dan sisanya $0.65 sampai $0.75 untuk biaya dari failure internal dan eksternal.

Penyeimbang BiayaKebutuhan 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 BiayaSedangkan 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 pengukuraninternal dan analisa data. Semakin tinggi tingkat kritis suatu proyek, biaya defect juga meningkat. Hal ini mengindikasikan banyak sumber daya dapat dialokasikan untuk mencapai proporsipenghilangan defect yang lebih tinggi. Seperti gambar disamping ini:

Siklus Hidup Software secaraUmumMetodologi 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 TestingApa 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 secaraUmumTahapan 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 UmumApabila 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 UmumSedangkan 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 SecaraUmum

- Biasanya bila pengguna telah merasa puas atau tes berjalan dengan

lancar / sukses.

* Alat bantu

- Komparator.

* Data

- Formalitas dokumen