ekuensialisasi tes dan estimasi tes.
Ma
5 Perenc
O b y e k t i f i t a s M a t e r i :
Memberikan pemahaman terhadap perencanaan testing.
Memberikan dasar-dasar pengembangan rencana testing beserta hal-hal yang berkaitan, termasuk s
teri:
Obyektifitas Rencana Testing
Rencana Tes Berdasarkan pada Standar IEEE Hal-Hal yang Berhubungan dengan Rencana Tes
nggi vs Spesifikasi Tes Detil
s
Kerangka Rencana Tes Sederhana
Testing Terstruktur vs Testing Tidak Terstruktur Spesifikasi Tes Tingkat Ti
Berapa Banyak Tes Dinyatakan Cukup? Sekuensialisasi Tes
Teknik Estimasi Usaha Te Faktor-Faktor Estimasi Estimasi Usaha Tes Penjadualan Usaha Tes
Bab V Perencanaan Testing Halaman 115
“Walaupun programer, tester dan manajer pemrograman tahu bahwa kode harus didisain dan ites, pada kenyataannya, banyak yang
disain dan dites – didisain oleh suatu p
d tidak memperhatikan bahwa tes itu sendiri harus di roses yang tidak kurang dalam hal kepastian dan
eizer Pada um dap aksi, dan bekerja di bawah tekanan batas waktu,
reliabilitas dari pemenuhan usaha stimasi rahkan ngan ketidakpastian, (4) sistem
kom nyak produk atau subsistem yang membutuhkan untuk diintegrasikan dan
pen ya dan jadual, dan resiko dari
sert ecahkan
ekusi tes.
pekendaliannya daripada yang digunakan untuk kode.”
Boris B umnya, kita berorientasi terha
sehingga terdapat kecenderungan untuk tidak melakukan perencanaan dan langsung saja menyelesaikan pekerjaan.
Mengapa proses testing harus direncanakan? Karena (1) pelanggan biasanya hanya memiliki sedikit kesabaran terhadap produk yang tidak memenuhi kualitas yang mereka harapkan, (2) tanpa adanya perencanaan dan organisasi, cakupan dan
tes hanyalah berupa dugaan, (3) tanpa adanya perencanaan dan organisasi, e kebutuhan jadual dan sumber daya tes, dan penilaian kesiapan sistem untuk dise berupa coba-coba dalam suatu kondisi yang penuh de
moderen, dengan teknologi GUI, client/server, dan teknologi baru lainnya, adalah sangat plek, dan ba
bekerja bersama, (5) serta tanpa organisasi yang efektif, efisiensi testing adalah rendah. Suatu rencana tes mendiskripsikan aktifitas testing, komponen-komponen yang dites,
dekatan testing, tiap alat bantu yang dibutuhkan, sumber da
aktifitas testing. Rencana tes digunakan untuk kesiapan dan pengorganisasian eksekusi tes, a memprediksikan solusi di depan terhadap permasalahan yang butuh untuk dip
kemudian saat proses eks
5.1 Obyektifitas Rencana Testing
Obyektifitas utama dari rencana testing adalah:Memfasilitasi tugas-tugas teknis dari testing, antara lain:
Meningkatkan cakupan tes: Daftar fitur, komponen, layar, pesan kesalahan,
engecekan proses kerja akan menghindarkan dari kelalaian
ningkatkan jumlah bug yang terlewatkan secara substansial.
konfigurasi hardware, dan lain-lain, akan mengurangi kelalaian yang mengakibatkan kurangannya cakupan dari testing.
Menghindarkan dari pengulangan yang tidak perlu: Berdasarkan pada daftar cek yang ada di dalam spesifikasi tes dan dokumentasi lainnya, akan menghindarkan dari redundansi usaha, dan p
pelaksanaan suatu tugas.
Menganalisa program untuk test cases yang baik: Di sini spesifikasi tes sangat membantu.
Menyediakan struktur: Tes integrasi akhir akan dapat dilakukan dengan lebih mudah tanpa mengalami tekanan karena struktur telah ada.
Meningkatkan efisiensi tes: Dengan mengurangi jumlah tes tanpa me
By Hendranet
Bab V Perencanaan Testing Halaman 116
Cek pemenuhan: Dengan melihat keseluruhan dari rencana tes terhadap ca area dari program, cakupan kelas-kelas bugs, cakupan kelas-kelas tes atau sederhana dari test cases.
kupan cakupan
san: Tentang akurasi dan cakupan a tes,
sikan ukuran dari pekerjaan dengan
kit atau terlalu banyak,
fokuskan diskusi saat rapat dan menghilangkan kebingungan.
pengaturan proses
entifikasi apa k akan) dilakukan oleh tester.
rang yang sama.
a yang melakukan tes, bagaimana mereka akan
anusia, dan lain-lain)
tugas mereka, membantu identifikasi
tes, dan melihat bilamana tak tercakup dalam rencana tes. Meningkatkan komunikasi tentang tugas-tugas dan proses-proses testing, antara lain:
Pemikiran strategi tes: Menerangkan pendekatan testing – apa, mengapa, dan bagaimana.
Mengembangkan umpan balik terhadap bata
testing – pembaca akan menunjukkan kekurangan dari rencan kesalahpahaman, dan kesalahan tes yang berpotensi lainnya di awal.
Ukuran dari pekerjaan testing: Mengkomunika
mengindikasikan semua area yang dites, menentukan jumlah tester, tenggang waktu testing, dan lain-lain.
Mengembangkan umpan balik terhadap kedalaman dan waktu: Rencana tes dapat menghasilkan banyak kontroversi – testing terlalu sedi
tenggang waktu dari jadual yang tidak diperlukan, dan lain-lain. Rencana tes membantu dalam mem
Akan lebih mudah untuk mendelegasikan dan mensupervisi testing suatu aplikasi bila dapat memberikan tester seperangkat instruksi yang tertulis dan detil.
Menyediakan struktur untuk pengorganisasian, penjadualan, dan testing, antara lain :
Mencapai persetujuan akan tugas-tugas tes: Secara spesifik mengid yang akan (dan tida
Mengidentifikasi tugas-tugas: Saat batasan didefinisikan, dapat menentukan sumber daya yang dibutuhkan (dana, waktu, manusia dan peralatan).
Struktur: Mengelompokan tugas-tugas yang sama, mengarahkan kelompok- kelompok tersebut ke o
Organisasi: Mengidentifikasi siap
melakukan tes, dimana, kapan dan dengan sumber daya apa (hardware/software khusus, m
Koordinasi: Mendelegasikan tugas berdasarkan pada seksi-seksi dari rencana tes. Meningkatkan akuntabilitas: Tester mengerti
masalah staf atau rencana tes tertentu, bilamana terdapat bug yang terlewatkan dari test cases, spesifikasi
Bab V Perencanaan Testing Halaman 117
5.2 Rencana Tes Berdasarkan pada
Standar IEEE
Standar IEEE [IEEE83A] mengidentifikasikan komponen-komponen utama dari rencana tes menurut struktur dari dokumen rencana tes, yaitu:
Identitas – memberikan identitas yang unik terhadap rencana.
Pengantar – memberikan gambaran besar (rangkuman) tentang apa saja yang terdapat membaca rencana lebih lanjut, dan menyediakan referensi ke dokumen
rikan identifikasi komponen-komponen yang akan dites, termasuk
tes.
pek sistem yang tidak akan dites dan
undaan dan pelaksanaan kembali – memberikan identifikasi kondisi- at ditunda, dan aktifitas testing apa yang harus diulang jika
umentasi yang ada di semua aktifitas testing, yang ang tercakup dalam rencana tes.
untuk melakukan tugas tersebut.
laskan lingkungan tes, termasuk tiap fasilitas hardware,
– memberikan spesifikasi terhadap siapa saja yang
n tes, dan proposal untuk koordinasi
kan identifikasi tiap asumsi resiko tinggi dari tingensi untuk tiap resiko yang terdaftar.
di dalam rencana, apa yang menjadi isu utama dimana pembaca harus melihatnya lebih detil jika mereka
yang lain.
Item-item tes – membe versi ataupun varian tertentu.
Fitur-fitur yang dites – mencakup aspek-aspek sistem yang akan di
Fitur-fitur yang tidak dites – mencakup aspek-as alasan mengapa mereka diabaikan.
Pendekatan – memberikan gambaran umum pendekatan testing tiap fitur yang dites.
Item kriteria berhasil/gagal – memberikan kriteria yang menentukan apakah tiap item tes berhasil atau gagal dites.
Kriteria pen
kondisi dimana testing dap testing dilaksanakan kembali.
Serahan tes – menjelaskan dok dipakai untuk item-item tes y
Tugas-tugas testing – memberikan identifikasi semua tugas-tugas yang dibutuhkan untuk menyelesaikan testing, termasuk depedensi antar tugas, atau kemampuan khusus yang dibutuhkan
Kebutuhan lingkungan – menje
fasilitas software, dan alat bantu pendukung yang khusus.
Tanggung jawab – mengelompokan tanggung jawab untuk mengatur (manage), mendisain, menyiapkan, mengeksekusi, melakukan kesaksian, melakukan cek, dan memecahkan masalah.
Stafing dan kebutuhan pelatihan
melaksanakan tugas-tugas testing, kebutuhan tingkat kemampuan, dan tiap kebutuhan akan pelatihan khusus.
Jadual – Memberikan batas-batas waktu dan kejadia tugas dan estimasi usaha.
Resiko dan kontingensi – memberi rencana, dan kon
Bab V Perencanaan Testing Halaman 118
Persetujuan – kebutuhan akan penandatanganan rencana, sebagai tanda bahwa rencana telah diketahui dan disetujui.
5.3 Hal-Hal yang Berhubungan dengan
Rencana Tes
Tes
mer Defined” – “TBD”
bagian-bagian dari rencana yang belum diketahui. Ter
dari embangan.
5.
ter dapat menjadi frustasi dalam menyelesaikan rencana tes sebelum detil sistem yang eka testing diselesaikan. Berdasarkan pada hal ini, skenario “To Be
dapat digunakan sebagai tanda untuk
minologi ini juga menyediakan suatu mekanisme sederana untuk pencarian bagian-bagian rencana yang masih membutuhkan peng