Pendekatan ini dengan menggunakan orang yang telah berpengalaman dan ahli untuk melakukan estimasi. Teknik ini dapat dilakukan bila terdapat minimal 2 orang ahli dalam melakukan estimasi, dimana masing-masing akan melakukan estimasi, dan hasilnya akan dianalisa bersama dalam suatu konsensus untuk mendapatkan nilai estimasi yang terbaik.
5.9.8 SWAG (Scientific Wild-Ass Guess)
Teknik ini dilakukan dengan membuat estimasi perencanaan kerja dalam rentan waktu ntu (dari
terte minimum (optimistik skenario) sampai maksimum (pesimistik skenario))
Update nilai tugas selanjutnya sesuai dengan pencapaian waktu (real) dalam pelaksanaan tiap tugas yang telah diselesaikan.
5.9.9 Re-Estimating by Phase
Estimasi tidak dipandang sebagai suatu aktivitas sekali proses jadi, namun sebagai proses yang dapat diperbaiki pada setiap fase pengembangan.
Bab V Perencanaan Testing Halaman 124
Tabel di bawah ini merupakan standar estimasi proyek:
Batas Waktu Cakupan Estimasi Akurasi
Studi Fisibilitas Keseluruhan Usaha Tes ± 50% Keseluruhan Usaha Tes ± 35% Dokumen Kebutuhan Sistem
Usaha Perencanaan Tes± 25% Keseluruhan Usaha Tes ± 25% Rencana Tes
Usaha Eksekusi Tes ± 25% Debugging dan Fixing ± 25% Penyelesaian Siklus Pertama dari
Eksekusi Tes Re-Testing ± 25%
Secara realistis, tingkat akurasi yang lebih rendah tidak akan dapat dicapai, kecuali proyek berukuran sangat kecil dan dengan tingkat resiko yang rendah.
5.10 Faktor-Faktor Estimasi
Beberapa faktor-faktor yang menjadi bahan pertimbangan dalam proses estimasi, antara lain: Kompleksitas dan ukuran produk
Jumlah dan kompleksitas fungsi, opsi, dan kondisi.
, dan data field.
, Server, dll).
hkan (seperti: performansi, kegunaan, dali, dll).
ersi, prosentase kode yang diubah pada rilis
ting yang telah dilakukan.
tim dan lingkungan pengembangan/perawatan.
tuk blackbox testing atau ekstensi yang
ul dan jalur kode yang dites. produk.
testing.
mpengaruhi strategi testing.
Jumlah dan kompleksitas komponen (program, obyek, modul, window, query, layar, laporan, dll).
Jumlah dan komplesitas table, data file
Jumlah dari antarmuka eksternal (ke / dari aplikasi lain, WAN Cakupan dan tipe testing yang dibutu
keamanan & ken Kesiapan testing produk
Kemapanan produk (Nomor v bersangkutan)
Ekstensi dan kredibilitas tes
Efektifitas dari kendali proses perubahan dan versi. Stabilitas
Resiko produk
Tingkat cakupan yang dibutuhkan un dibutuhkan testing.
Prosentase cakupan dari program, mod Tingkat kepentingan integritas data Penggunaan dan ekstensi dari pilot/field Penggunaan dan ekstensi dari volume testing. Penggunaan dan ekstensi dari regression testing. Tingkat dimana deadline dan anggaran akan me
Bab V Perencanaan Testing Halaman 125
Efisiensi infrastruktur pendukung dan proses eksekusi tes
nsi yang diantisipasi dari penggunaan alat bantu otomatisasi. stem operasi yang harus dites.
an dan kesiapan lingkungan tes. dan keberadaan sumber daya
ng dites.
lingkungan tes, alat bantu tes dan metode. untuk tes terhadap tuntutan yang lain.
individu.
apa usaha tes pada grup yang lain (seperti
5.11
stimasi Usaha Tes
Tingkat otomatisasi yang direncanakan. Keberadaan dan ekste
Jumlah si
Stabilitas, kekomplit Kemampuan tester
Pengalaman testing tertentu. Keterbiasaan terhadap sistem ya Keterbiasaan terhadap
Waktu yang ada
Faktor manusia, seperti produktivitas, motivasi dan tingkat energi Kemampuan untuk mendelegasikan beber
pengembang, pengguna).
E
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:
5.11.1 Perencanaan tes
Fak h:
s.
J u m l a h
tor-faktor kunci yang diperhitungkan, adala
Jumlah test cases yang dibutuhkan untuk testing. Waktu rata-rata per test case untuk persiapan test case
t e s t c a s e s y a n g d i b u t u h k a n u n t u k t e s t i n g
Dat m perencanaan
jumlah test cases untuk testing software baru bila ditinjau
er 300 sampai 500 LOC per fungsi untuk system testing, dengan intensitas a industri praktis untuk estimasi jumlah test cases yang dibutuhkan dala
tes, dibagi menjadi dua bagian, yaitu (1) untuk testing software baru, dan (2) untuk regression testing.
E s t i m a s i j u m l a h t e s t c a s e s u n t u k t e s t i n g s o f t w a r e b a r u
Data industri praktis estimasi
berdasarkan intensitasnya, antara lain:
1 test case per 1 LOC per fungsi untuk system testing beresiko tinggi.
1 test case per 30 sampai 50 LOC per fungsi untuk system testing rata-rata, dengan intensitas tes yang biasa.
1 test case p
tes minimal (cocok untuk sistem dengan resiko dan kompleksitas rendah, dan dengan asumsi bahwa review kualitas serta unit dan integration testing tertentu telah dilakukan).
Bab V Perencanaan Testing Halaman 126
Data di atas untuk functional testing pada tingkat sistem, sedangkan untuk unit testing rata- , tiap 1 test case dibutuhkan penambahan 7 sampai 1
rata 2 LOC.
berd
atau Cobol.
test case untuk tiap 10-15 LOC. dimana dalam bahasa C atau Cobol LOC bila dibuat, ya defect untuk program dalam bahasa mesin lebih 5 defect saat dilakukan
an untuk satu fungsi yang sama,
a dala m bahasa visual atau 4GL dibutuhkan
15 sampai 30 LOC, dengan kemungkinan defect yang dihasilkan kurang lebih sama, 1
h LOC dari software yang dites, sehingga metode n. Dalam kasus ini, jumlah test cases dapat
nya, seperti detil fitur dalam kebutuhan
test case per detil fitur dalam kebutuhan fungsional (sederhana, resiko
nal (komplek, resiko tinggi)
se per halaman kebutuhan fungsional atau dokumentasi spesifikasi
ery (komplek, resiko tinggi)
Sed ang
kasi.
odifikasi.
Data industri praktis estimasi jumlah test cases untuk testing software baru bila ditinjau asarkan bahasa pemrograman yang digunakan, antara lain:
Rasio 1 test case per 30 – 50 LOC digunakan pada bahasa pemrograman tradisional generasi ketiga seperti C
Untuk bahasa assembly atau bahasa mesin, rasio 1 Sebagai perbandingan untuk satu fungsi yang sama,
dibutuhkan 100 LOC, dalam bahasa mesin dibutuhkan kurang lebih 325 dan umumnya kemungkinan terjadin
besar, dimana untuk 325 LOC akan mengandung 10 sampai 1 system testing.
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 perbanding
diman m bahasa C dibutuhkan 100 LOC, dala
sampai 1,5 defect per 100 LOC. Kadangkala tester tidak mengetahui jumla perhitungan di atas tidak dapat digunaka
diestimasi berdasarkan pada ukuran software lain
fungsional, function point, halaman dokumen kebutuhan fungsional atau spesifikasi, query, dan window, dengan data industri praktis sebagai berikut:
2 sampai 3 rendah)
10 sampai 12 test case per detil fitur dalam kebutuhan fungsio 2 sampai 3 test case per function point
20 sampai 30 test ca
2 sampai 3 test case per query (sederhana, resiko rendah) 10 sampai 15 test case per qu
5 sampai 10 test case per window (sederhana, resiko rendah) 10 sampai 25 test case per window (komplek, resiko tinggi)
E s t i m a s i j u m l a h t e s t c a s e s u n t u k r e g r e s s i o n t e s t i n g
angkan data industri praktis dalam melakukan estimasi jumlah test cases y dibutuhkan untuk regression testing, ada tiga kelompok utama, yaitu:
Untuk komponen software baru atau yang dimodifi
Membutuhkan jumlah test cases yang sama dengan software baru. Untuk komponen software yang berhubungan namun tidak dim
Bab V Perencanaan Testing Halaman 127
Untuk regression test lengkap, membutuhkan jumlah test case yang sama dengan
tuhkan 10% dari jumlah test
re yang tidak berhubungan dan tidak dimodifikasi.
Untuk regres 10% dari jumlah test
cases softwar
Untuk regress erhana, me kan 1% % dari jumlah test cases softwar