Metodologi Rasional Rose
6.8 Testing Dengan Review
Pada awalnya review adalah alat bantu pengendalian manajemen. Selama proyek berlangsung, manajemen memerlukan suatu penilaian dan pengukuran kinerja proses yang telah berlangsung. Jadi obyektifitas dari review adalah untuk mendapatkan informasi yang
biasanya berupa status dan atau kualitas kerja.
esifikasi, disain, coding, prosedural, in tes, prosedur tes dan rencana tes.
testing lainnya, yang berarti review
n iew dapat ditempatkan dimana saja ik dimana hasil utama dari konsisten dan dapat dipercaya,
Terdapat banyak jenis dari review, yaitu: kebutuhan, sp dokumentasi, konversi, instalasi, implementasi, disa
Praktisioner pada umumnya, memandang review adalah suatu hal yang terpisah dari testing, karena kebanyakan masih memandang testing dalam sudut pandang testing yang lama. Bila testing digunakan sebagai pengukuran kualitas software, maka sebenarnya akan tepat bila memasukan review sebagai satu-satunya teknik testing yang ada untuk aktifitas awal dari pengembangan. Adalah sangat mendasar untuk melihat review sebagai suatu tes dan memastikannya bekerja dengan efektif layaknya teknik
harus juga direncanakan terhadap apa yang akan dites, kapan selesai dan siapa yang bertanggung jawab.
Review hadir dalam dua bentuk, yaitu (1) formal dan (2) tidak formal. Yang dipandang sebagai teknik testing adalah review dalam bentuk formal, dimana partisipan bertanggung jawab untuk melakukan kalkulasi secara akurat dan menghasilkan laporan dari apa yang telah mereka temukan bagi manajemen.
Tahap pertama untuk mencapai suatu siklus hidup yang efektif adalah memilih serangkaia titik-titik penempatan dimana formal review diadakan. Rev
sepanjang siklus pengembangan. Umumnya dilakukan di tiap tit
suatu tahap pengembangan dihasilkan dan sekaligus sebagai titik penentuan terselesaikannya aktifitas pada fase tersebut. Jumlah review yang dibutuhkan untuk
Bab VI Proses Testing Halaman 153
karakter dari proyek software. Beberapa potensial review yang penting berdasarkan pada tujuan atau hasil yang diharapkan, dapat dilihat pada tabel berikut.
Review Tujuan atau Hasil yang Diharapkan
Kebutuhan Sistem Mengetahui apa yang seharusnya dilakukan oleh sistem. Kebutuhan Software Menyetujui terhadap kebutuhan spesifikasi dan inisialisasi disain awal. Rencana Tes Utama Menyetujui terhadap keseluruhan strategi dan pendekatan tes. Disain Awal Menetapkan dasar bagi disain awal. Menyetujui pendekatan
disain dasar untuk software dan tes.
Disain Kritikal Menyetujui disain detil. Otorisasi untuk memulai coding dan implementasi tes. Modul Menyetujui penyelesaian tiap unit dan rilis dari modul ke formal
testing.
System Test Menyetujui penyelesaian dari system testingdan otorisasi untuk memulai acceptance testing.
Acceptance Test Menerima produk, dan menyetujui implementasi operasional. Rencana review secara minimum, harus terdiri dari:
Siapa saja yang diharapkan akan hadir.
Informasi yang dibutuhkan sebelum memulai review.
Kondisi awal yang harus dipenuhi sebelum review dilakukan.
Daftar kegiatan atau item atau indikasi lainnya yang bersangkutan dengan apa yang akan dibahas.
Kodisi akhir atau kriteria yang harus dipenuhi agar review dapat dinyatakan selesai. Data dan dokumentasi disimpan.
Rencana ini juga harus menunjuk penanggung jawab untuk persiapan dan pelatihan review
yang baik tidaklah mudah. Sebagaimana halnya aktu. Biasanya akan yek untuk pekerjaan
eventual untuk mendisain review, dan lima sampai lima belas jam anapun, penggunaan suatu aturan yang
terla nghancurkan review. Review atau
test dan obyektifitas harus ada
bes na, obyektifitas, dan
kendali dari pekerjaan testing, bukan berdasarkan pad
Beb w, adalah:
bagi partisipan, untuk penjadualan dan pengorganisasian review, dan untuk pelaporan hasil. Review merupakan satu-satunya testing yang efektif bagi fase awal dari pengembangan software. Namun instalasi suatu review
dengan tipe testing yang lainnya, review juga membutuhkan investasi w dianggarkan empat persen sampai delapan persen dari total biaya pro
review. Werner Frank, presiden dari Informatics, menyarankan dari dua sampai enam jam per seribu baris kode secara
per seribu baris untuk review logika kode. Bagaim lu secara literatur akan membahayakan dan dapat me ing pada umumnya, harus direncanakan dengan hati-hati erta pencatatan waktu dan sumber daya yang dibutuhkan. Renca hasil yang diharapkan harus menjadi dasar
a standar artifisial atau jumlah waktu dan uang yang ada. erapa faktor kritis bagi kesuksesan dari revie
Hasil yang diharapkan
Mengetahui tujuan dari review. Apa yang dites dan diukur?
By Hendranet
Bab VI Proses Testing Halaman 154
Pertanggungjawaban
Secara jelas menetapkan tanggung jawa dari seluruh partisipan. Hak individu
Melindungi opini dan perasaan individu, bukan komite.
benar, beberapa dari luar dan beberapa dari dalam.
integrasi dari review tes dan review software, seperti terlihat pada tabel di bawah Kehadiran
Orang-orang yang Proses yang terstruktur
Menetapkan prosedur-prosedur. Moderator
Berpengalaman dan terlatih. Data
Laporan dan evaluasi tertulis.
Dari ketujuh faktor ini, ketiga faktor pertama yang paling banyak diabaikan. Apa yang diharapkan dari review dan tanggung jawab seluruh partisipan harus diutarakan dengan jelas. Sangat penting untuk menampung opini tiap individu. Adalah cara terburuk untuk mencapai suatu informasi teknis yang akurat dengan cara voting atau keputusan berdasarkan pada suara terbanyak. Seperti yang telah disebutkan di awal, rencana review bertugas untuk mengatur secara tepat hubungan antar faktor-faktor ini dan mengorganisasikan review secara tepat pula.
Selain produk-produk di tiap fase pengembangan awal, penting pulan bagi produk testing untuk direview. Produk-produk testing yang dapat direview, antara lain:
Rencana tes (utama dan tiap tingkat). Spesifikasi disain tes.
Spesifikasi. Prosedur tes. Test cases. Laporan tes. Inventori. Sedangkan ini.
Review Produk tes yang ada di dalam review
Kebutuhan Rencana tes utama. Spesifikasi acceptance test. Disain Spesifikasi system test. Spesifikasi integration test.
Rencana tes utama yang telah diubah. Disain Detil Spesifikasi tes modul atau program. Kode Tes program dan tes prosedur. Implementasi Hasil tes dan rangkuman laporan.
Bab VI Proses Testing Halaman 155
Rencana tes utama dan spesifikasi acceptance test harus dimasukan dan direview sebagai salah satu bagian dari review fase kebutuhan. Spesifikasi system dan integration test harus direview bersama dengan review disain software. Spesifikasi tes modul atau program harus direview pada saat yang sama dengan review disain detil dari modul atau program
tan. S dari modul
doco aat review
bersangku erangkaian unit test harus direview bersama dengan review kode atau pseu de. Akhirnya laporan tes dan hasil tes akan direview pada s kesiapan implementasi secara keseluruhan dilakukan.
Kombinasi review tes dan review software memberikan penekanan kepada pentingnya testing dan pengukuran dari kualitas produk tes tanpa penambahan beban atau kompleksitas pada keseluruhan siklus hidup proses.