1. Perencanaan Testing

2. Menyesal sama seperti mengejar
bayangan kita sendiri, semakin
dikejar, semakin jauh dari jalan
keluar

3. Pada umumnya, kita berorientasi terhadap aksi, dan bekerja di bawah tekanan
batas waktu, 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 reliabilitas dari
pemenuhan usaha tes hanyalah berupa dugaan,
(3) tanpa adanya perencanaan dan organisasi, estimasi kebutuhan jadwal dan
sumber daya tes, dan penilaian kesiapan sistem untuk diserahkan berupa coba-
coba dalam suatu kondisi yang penuh dengan ketidakpastian,
PERENCANAAN TESTING

4. (4) sistem moderen, dengan teknologi GUI, client/server, dan teknologi baru
lainnya, adalah sangat komplek, dan banyak produk atau subsistem yang
membutuhkan untuk diintegrasikan dan bekerja bersama.
(5) Serta tanpa organisasi yang efektif, efisiensi testing adalah rendah. Suatu
rencana tes mendiskripsikan aktifitas testing, komponen-komponen yang
dites, pendekatan testing, tiap alat bantu yang dibutuhkan, sumber daya
dan jadual, dan resiko dari aktifitas testing.
Rencana tes digunakan untuk kesiapan dan pengorganisasian eksekusi
tes, serta memprediksikan solusi di depan terhadap permasalahan yang
butuh untuk dipecahkan kemudian saat proses eksekusi tes.

5. Obyektifitas utama dari rencana testing adalah  memfasilitasi tugas-tugas
teknis
‰Memfasilitasi tugas-tugas teknis dari testing, antara lain:
1. ƒMeningkatkan cakupan tes yang dapat mengurangi kelalaian yang
mengakibatkan kurangannya cakupan dari testing.
2. ƒ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
pengecekan proses kerja akan menghindarkan dari kelalaian pelaksanaan
suatu tugas.
Obyektifitas Rencana Testing

6. Cara menganalisa program untuk test cases yang baik :
a. Menyediakan struktur: Tes integrasi akhir akan dapat dilakukan dengan
lebih mudah tanpa mengalami tekanan karena struktur telah ada.
b. Meningkatkan efisiensi tes: Dengan mengurangi jumlah tes tanpa
meningkatkan jumlah bug yang terlewatkan secara substansial.
c. Cek pemenuhan: Dengan melihat keseluruhan dari rencana tes terhadap
cakupan area dari program, cakupan kelas-kelas bugs, cakupan kelas-kelas
tes atau cakupan sederhana dari test cases.

7. Meningkatkan komunikasi tentang tugas-tugas dan proses-proses testing,
antara lain:
a. Mengembangkan umpan balik terhadap batasan: Tentang akurasi dan
cakupan testing – pembaca akan menunjukkan kekurangan dari rencana
tes, kesalahpahaman, dan kesalahan tes yang berpotensi lainnya di awal.
b. ƒUkuran dari pekerjaan testing: Mengkomunikasikan ukuran dari pekerjaan
dengan mengindikasikan semua area yang dites, menentukan jumlah
tester, tenggang waktu testing, dan lain-lain.
c. Mengembangkan umpan balik terhadap kedalaman dan waktu:
Rencana tes dapat menghasilkan banyak kontroversi – testing terlalu sedikit
atau terlalu banyak, tenggang waktu dari jadual yang tidak diperlukan, dan
lain-lain. Rencana tes membantu dalam memfokuskan diskusi saat rapat
dan menghilangkan kebingungan. Akan lebih mudah untuk mendelegasikan
dan mensupervisi testing suatu aplikasi bila dapat memberikan tester
seperangkat instruksi yang tertulis dan detil.

8. Manfaat menyediakan struktur untuk pengorganisasian, penjadualan, dan
testing, antara lain :
a. Mencapai persetujuan akan tugas-tugas tes: Secara spesifik
mengidentifikasi apa yang akan (dan tidak akan) dilakukan oleh tester.
b. ƒMengidentifikasi tugas-tugas: Saat batasan didefinisikan, dapat
menentukan sumber daya yang dibutuhkan (dana, waktu, manusia dan
peralatan).
c. ƒTerstruktur: Mengelompokan tugas-tugas yang sama, mengarahkan
kelompok- kelompok tersebut ke orang yang sama.
d. ƒTerorganisir: Mengidentifikasi siapa yang melakukan tes, bagaimana
mereka akan melakukan tes, dimana, kapan dan dengan sumber daya apa
(hardware/software khusus, manusia, dan lain-lain)

9. e. Koordinasi: Mendelegasikan tugas berdasarkan pada seksi-seksi dari
rencana tes.
f. Meningkatkan akuntabilitas: Tester mengerti tugas mereka, membantu
identifikasi masalah staf atau rencana tes tertentu, bilamana terdapat bug
yang terlewatkan dari test cases, spesifikasi tes, dan melihat bilamana tak
tercakup dalam rencana tes.

10. Standar IEEE [IEEE83A] mengidentifikasikan komponen-komponen utama dari
rencana tes menurut struktur dari dokumen rencana tes, yaitu:
1. ‰Identitas – memberikan identitas yang unik terhadap rencana.
2. ‰Pengantar – memberikan gambaran besar (rangkuman) tentang apa saja
yang terdapat di dalam rencana, apa yang menjadi isu utama dimana
pembaca harus melihatnya lebih detil jika mereka membaca rencana lebih
lanjut, dan menyediakan referensi ke dokumen yang lain.
3. ‰Item-item tes – memberikan identifikasi komponen-komponen yang akan
dites, termasuk versi ataupun varian tertentu.
Rencana Tes Berdasarkan pada Standar IEEE

11. 4. Fitur-fitur yang dites – mencakup aspek-aspek sistem yang akan dites.
5. ‰Fitur-fitur yang tidak dites – mencakup aspek-aspek sistem yang tidak
akan dites dan alasan mengapa mereka diabaikan.
6. ‰Pendekatan – memberikan gambaran umum pendekatan testing tiap fitur
yang dites.
7. ‰Item kriteria berhasil/gagal – memberikan kriteria yang menentukan
apakah tiap item tes berhasil atau gagal dites.
8. ‰Kriteria penundaan dan pelaksanaan kembali – memberikan
identifikasi kondisi- kondisi dimana testing dapat ditunda, dan aktifitas
testing apa yang harus diulang jika testing dilaksanakan kembali.

12. 9. Serahan tes – menjelaskan dokumentasi yang ada di semua aktifitas
testing, yang dipakai untuk item-item tes yang tercakup dalam rencana tes.
10. ‰Tugas-tugas testing – memberikan identifikasi semua tugas-tugas yang
dibutuhkan untuk menyelesaikan testing, termasuk depedensi antar tugas, atau
kemampuan khusus yang dibutuhkan untuk melakukan tugas tersebut.
11. ‰Kebutuhan lingkungan – menjelaskan lingkungan tes, termasuk tiap fasilitas
hardware, fasilitas software, dan alat bantu pendukung yang khusus.
12. ‰Tanggung jawab – mengelompokan tanggung jawab untuk mengatur
(manage), mendisain, menyiapkan, mengeksekusi, melakukan kesaksian,
melakukan cek, dan memecahkan masalah.

13. 13.Stafing dan kebutuhan pelatihan – memberikan spesifikasi terhadap
siapa saja yang melaksanakan tugas-tugas testing, kebutuhan tingkat
kemampuan, dan tiap kebutuhan akan pelatihan khusus.
14.‰Jadwal – Memberikan batas-batas waktu dan kejadian tes, dan proposal
untuk koordinasi tugas dan estimasi usaha.
15.‰Resiko dan kontingensi – memberikan identifikasi tiap asumsi resiko
tinggi dari rencana, dan kontingensi untuk tiap resiko yang terdaftar.
16.Persetujuan – kebutuhan akan penandatanganan rencana, sebagai
tanda bahwa rencana telah diketahui dan disetujui.

14. Tester dapat menjadi frustasi dalam menyelesaikan rencana tes sebelum
detil sistem yang mereka testing diselesaikan. Berdasarkan pada hal ini,
skenario “To Be Defined” – “TBD” dapat digunakan sebagai tanda untuk
bagian-bagian dari rencana yang belum diketahui. Terminologi ini juga
menyediakan suatu mekanisme sederana untuk pencarian bagian-bagian dari
rencana yang masih membutuhkan pengembangan.
Hal-Hal yang Berhubungan dengan Rencana Tes

15. Secara sederhana dokumen rencana tes, terdiri dari:
1. ‰Obyektifitas, berisi tujuan akhir yang akan dicapai oleh testing, dan produk testing
yang diharapkan.
2. ‰Strategi dan pendekatan, berisi diskripsi lingkungan tes, dan cakupan dari testing.
3. ‰Spesifikasi tes, untuk tiap bagian-bagian dari tes, berisi diskripsi tes, data masukan,
kondisi inisial yang dibutuhkan, dan hasil yang diharapkan.
4. ‰Rencana kerja dan jadual tes, berisi tentang daftar tugas-tugas testing secara
berurutan (sekuensial), kriteria dan rencana tes ulang, batasan waktu secara umum.
5. ‰Kriteria pemenuhan sumber daya, berisi indentifikasi tim tes, jam-perorang yang
dibutuhkan untuk testing, dan alat bantu tes otomatis yang digunakan (bila ada).
Kerangka Rencana Tes Sederhana

16. • Suatu tes yang terstruktur adalah yang direncanakan, didefinisikan, dan
didokumentasikan. Testing yang terstruktur menggunakan suatu strategi yang
dapat diharapkan berdasar pada analisa rasional dari sistem, lingkungan,
kegunaan dan resiko.
• Suatu tes yang tidak terstruktur tidak direncanakan sebelumnya, dilakukan
berdasarkan spontanitas dan kreatifitas.
• Testing tidak dapat 100% terstruktur ataupun 100% tidak terstruktur. Testing
selalu berada diantaranya. Karena testing yang hanya menggunakan
metode terstruktur membutuhkan usaha yang amat keras dalam pembuatan
rencana tes. Sedangkan untuk testing yang tidak terstruktur, cakupan tes tidak
dapat diketahui dan tidak diulang secara konsisten. Idealnya perbandingan
bobot antara terstruktur dan tidak terstruktur adalah 75% dan 25%.
Testing Terstruktur vs Testing Tidak Terstruktur

17. TERIMA KASIH