Estimasi Usaha Tes: • Perencanaan tes • Eksekusi tes • Debugging dan Perbaikan

1. Estimasi Usaha Tes

2. Jangan batasi impianmu dengan
pendapat orang lain

3. Faktor-faktor kunci yang diperhitungkan dalam melakukan usaha
tes bervariasi di tiap tahapan dari siklus hidup tes. Adapun faktor-faktor kunci
di tiap fase tersebut, beserta beberapa data industri praktis yang merupakan
data efektif secara umum yang terdapat pada organisasi software, dan dapat
digunakan sebagai acuan awal dalam melakukan estimasi, adalah sebagai
berikut :
1. Perencanaan tes
Faktor-faktor kunci yang diperhitungkan, adalah:
a.‰Jumlah test cases yang dibutuhkan untuk testing.
b.‰Waktu rata-rata per test case untuk persiapan test cases.
Estimasi Usaha Tes

4. ❖ Jumlah test cases yang dibutuhkan untuk testing
Data industri praktis untuk estimasi jumlah test cases yang dibutuhkan
dalam perencanaan tes, dibagi menjadi dua bagian, yaitu :
(1) Untuk testing software baru
(2) Untuk regression testing.

5. ❖ Estimasi jumlah test cases untuk testing software baru
Data industri praktis estimasi jumlah test cases untuk testing software baru
bila ditinjau berdasarkan intensitasnya, antara lain :
a. ‰1 test case per 1 LOC per fungsi untuk system testing beresiko tinggi.
b. 1 test case per 30 sampai 50 LOC per fungsi untuk system testing rata-
rata, dengan intensitas tes yang biasa.
c. ‰1 test case per 300 sampai 500 LOC per fungsi untuk system testing,
dengan intensitas tes minimal (cocok untuk sistem dengan resiko dan
kompleksitas rendah, dan dengan asumsi bahwa review kualitas serta
unit dan integration testing tertentu telah dilakukan).

6. Data di atas untuk functional testing pada tingkat sistem, sedangkan untuk unit testing
rata- rata, tiap 1 test case dibutuhkan penambahan 7 sampai 12 LOC. Data industri
praktis estimasi jumlah test cases untuk testing software baru bila ditinjau berdasarkan
bahasa pemrograman yang digunakan, antara lain :
a. Rasio 1 test case per 30 – 50 LOC digunakan pada bahasa pemrograman tradisional
generasi ketiga seperti C atau Cobol.
b. ‰Untuk bahasa assembly atau bahasa mesin, rasio 1 test case untuk tiap 10-15 LOC.
c. Sebagai perbandingan untuk satu fungsi yang sama, dimana dalam bahasa C atau
Cobol dibutuhkan 100 LOC, dalam bahasa mesin dibutuhkan kurang lebih 325 LOC
bila dibuat, dan umumnya kemungkinan terjadinya defect untuk program dalam
bahasa mesin lebih besar, dimana untuk 325 LOC akan mengandung 10 sampai 15
defect saat dilakukan system testing.

7. d. Untuk bahasa pemrograman visual atau 4GL seperti Visual Basic, Visual
C++ dan Power Builder, rasio 1 test case per 30-50 LOC, dan 1 test case
per 300-500 LOC untuk LOC yang dikodekan secara otomatis. Sebagai
perbandingan untuk satu fungsi yang sama, dimana dalam bahasa C
dibutuhkan 100 LOC, dalam bahasa visual atau 4GL dibutuhkan 15 sampai
30 LOC, dengan kemungkinan defect yang dihasilkan kurang lebih sama, 1
sampai 1,5 defect per 100 LOC.

8. Kadangkala tester tidak mengetahui jumlah LOC dari software yang dites,
sehingga metode perhitungan di atas tidak dapat digunakan. Dalam kasus
ini, jumlah test cases dapat diestimasi berdasarkan pada ukuran software
lainnya, seperti detil fitur dalam kebutuhan fungsional, function point, halaman
dokumen kebutuhan fungsional atau spesifikasi, query, dan window, dengan
data industri praktis sebagai berikut :

9. A. 2 sampai 3 test case per detil fitur dalam kebutuhan fungsional (sederhana,resiko
rendah)
B. 10 sampai 12 test case per detil fitur dalam kebutuhan fungsional (komplek, resiko
tinggi)
C. ‰2 sampai 3 test case per function point
D. 20 sampai 30 test case per halaman kebutuhan fungsional atau dokumentasi
spesifikasi
E. 2 sampai 3 test case per query (sederhana, resiko rendah)
F. 10 sampai 15 test case per query (komplek, resiko tinggi)
G. 5 sampai 10 test case per window (sederhana, resiko rendah)
H. 10 sampai 25 test case per window (komplek, resiko tinggi)

10. Faktor-faktor kunci yang diperhitungkan, adalah :
a. ‰Jumlah siklus tes (seperti seberapa sering siklus/pengulangan dari suatu
test case).
b. ‰Jumlah test cases yang dieksekusi per siklus atau batch tes.
c. ‰Waktu yang dibutuhkan untuk menjalankan per tes.
d. Cakupan usaha yang diestimasi untuk eksekusi tes meliputi :
Eksekusi tes

11. 1. Persiapan (waktu untuk membaca dan mengerti test cases)
2. ‰Set-up lingkungan tes
3. ‰Eksekusi tes
4. ‰Mendapatkan hasil tes
5. ‰Evaluasi hasil tes
6. ‰Menentukan status keberhasilan test cases
7. ‰Pencatatan dan pelaporan hasil tes
‰Bila terjadi kegagalan tes:
1. Replikasi hasil
2. Penambahan eksekusi untuk memastikan pemahaman masalah
3. ƒKoleksi informasi diagnosa bersangkutan
4. ƒMenulis laporan masalah
5. ƒReview laporan masalah dengan orang yang bertanggung jawab dengan
debugging dan fixing

12. Estimasi waktu yang dibutuhkan untuk menjalankan per test case
tergantung pada lingkungan tes yang digunakan. Tidak ada petunjuk yang
dapat digunakan dalam melakukan estimasi terhadap persiapan dan set-up
lingkungan tes. Usaha yang dibutuhkan mempunyai cakupan dari yang kecil
(trivial) sampai pada keseluruhan usaha eksekusi tes yang dibutuhkan.
Faktor trivial dalam estimasi lingkungan tes adalah :

13. 1. Lingkungan tes telah ditetapkan dan ada, dan tester telah mengetahui
bagaimana menggunakan fasilitas tes secara efektif.
2. Lingkungan tes belum ditetapkan, namun hanya dibutuhkan set-up
sederhana dan mempunyai biaya overhead perawatan yang rendah.
3. Banyak test cases yang akan dijalankan pada satu konfigurasi atau
lingkungan tes umum, tidak banyak dibutuhkan perubahan lingkungan,
sehingga usaha set-up dapat dianggap kecil bila dibandingkan dengan
dengan jumlah tes yang besar.

14. Pada lingkungan yang komplek, estimasi usaha set-up dan perawatan lingkungan,
meliputi usaha-usaha sebagai berikut :
1. ‰Mendaftar fasilitas-fasilitas tes yang ada dan menilai kelayakannya.
2. ‰Mendefinisikan lingkungan yang digunakan sebagai dasar untuk serangkaian
tes yang direncanakan. Tidak perlu memperhitungkan hal-hal minor, namun hal-
hal yang membutuhkan waktu ekstra, seperti perawatan repositori test cases
dan manajemen konfigurasi.
3. Menentukan berapa banyak variasi yang dibutuhkan dalam testing pada
lingkungan yang digunakan sebagai dasar, dan mengkategorikannya apakah
sebagai konfigurasi ulang yang minor atau sebagai pembuatan ulang yang
mayor.

15. Mengembangkan suatu daftar detil dari tahapan atau aktifitas kerja yang
dibutuhkan untuk mengembangkan dan merawat lingkungan ini. Mengestimasi
jumlah waktu yang dibutuhkan untuk tiap aktifitas kerja. Dan menetapkan
batasan waktu strategis yang dibutuhkan untuk menunggu pengadaan
komponen yang dibutuhkan dari vendor, serta waktu yang dibutuhkan untuk
debugging, perbaikan dan testing lingkungan tes.

16. ❖ Faktor kunci yang digunakan untuk estimasi adalah:
1. Jumlah defects/bugs yang diperbaiki.
2. Waktu perbaikan untuk tiap defect/bug
A. Jumlah defects/ bugs yang diperbaiki
Data praktis industri yang dapat digunakan sebagai acuan awal estimasi jumlah
defects/bugs bila ditinjau berdasarkan bahasa pemrograman dan fase dimana testing
dilakukan, adalah sebagai berikut:
a. ‰5 sampai 8 defects/bugs per 100 LOC (untuk kode baru, sebelum unit test, dengan
bahasa pemrograman generasi ketiga, seperti C atau cobol).
b. ‰10 sampai 15 defects/bugs per 100 LOC (untuk kode baru, sebelum unit test, dengan
bahasa assembly).
c. ‰1,5 defects/bugs per 100 LOC (untuk kode baru dengan bahasa generasi ke-3, sebelum
integration dan system test).
Debugging dan Perbaikan

17. d. 2 sampai 3 defects/bugs per 100 LOC dari daerah bermasalah (untuk modifikasi
dengan bahasa generasi ke-3, kode terstruktur dengan baik, sebelum unit test).
e. ‰10 sampai 15 defects/bugs per 100 LOC dari daerah bermasalah (untuk
modifikasi dengan bahasa generasi ke-3, kode tidak terstruktur dengan baik,
sebelum unit test).
f. ‰4 sampai 6 defects/bugs per 1000 LOC (untuk kode baru dengan bahasa
generasi ke-3, diserahkan ke klien) untuk aplikasi in-house MIS.
g. ‰2 sampai 3 defects/bugs per 100 LOC (untuk kode baru dengan bahasa
generasi ke-3, diserahkan ke klien) untuk paket produk dari vendor software.

18. ❖ Waktu Yang Dibutuhkan Untuk Memperbaiki Defect/ Bug
Menurut Jack Adams dari IBM, waktu yang dibutuhkan untuk
memperbaiki defects/bugs meningkat seiring dengan jumlah defects/bugs
yang ditemukan. Adams memberikan waktu rata-rata untuk perbaikan
defect/bug, sebagai berikut: Jumlah defects sedikit, Jumlah defects
sampai 10 defects, dan dalam suatu lingkungan debugging dan
perbaikan langsung, waktu perbaikan per defect berdasarkan pada tingkat
kesulitan:

20. Jumlah defects banyak Jumlah defects 100 defects atau lebih, dan dalam
suatu lingkungan debugging dan perbaikan yang lebih komplek, waktu
perbaikan per defect berdasarkan pada tingkat kesulitan:

21. TERIMA KASIH