• Tidak ada hasil yang ditemukan

Pend ekatan debugging

Dalam dokumen Modul testing dan implementasi sistem Kartika (Halaman 119-124)

4 1 4 Kriteria pemenuha n tes t ing

4.6 Syst em Testing

4.7.3 Pend ekatan debugging

Pada umumnya ada tiga kategori pendekatan debugging [MYE79], yaitu:

Brute force adalah metode paling umum dan tidak efisien untuk isolasi penyebab error

dari software. Penerapan brute force, hanya dilakukan bilamana pendekatan yang lain

telah gagal. Dengan menggunakan filosofi “biarkan komputer menemukan error”, seperti

terjadinya kekurangan memori, dll, diharapkan dimana pada suatu kekacauan informasi yang dihasilkan, akan dapat ditemukan petunjuk yang dapat menuntun ke penyebab dari suatu error. Walaupun banyak informasi yang dihasilkan akan membuat proses

debugging sukses, akan banyak pula hal-hal yang menghabiskan usaha dan waktu

secara percuma. Akal harus digunakan terlebih dahulu!

BackTracking adalah metode cukup umum yang biasanya digunakan untuk program

kecil. Dimulai dari dimana indikasi telah dicakup, source codes dilacak ke belakang

secara manual sampai ke tempat dimana penyebab ditemukan. Sayangnya, seiring dengan makin meningkatnya jumlah baris kode, jumlah jalur potensial pelacakan ke belakang akan menjadi semakin banyak pula dan tak termanajemeni.

Cause Elemenation adalah manifestasi induksi atau deduksi dan menggunakan konsep

binary partitioning. Data yang berhubungan dengan error diorganisasi untuk mengisolasi penyebab yang potensial. Suatu hipotesa penyebab dikembangkan dan data yang dibutuhkan untuk membuktikan atau menggagalkan hipotesa tersebut.

Sebagai alternatif, suatu daftar dari semua kemungkinan penyebab dikembangkan dan lakukan tes untuk menghilangkan tiap kemungkinan tersebut. Jika tes inisial mengindikasikan bahwa suatu bagian hipotesa penyebab terlihat berpotensi, data

dibentuk dalam rangka untuk mengisolasi bug.

Bila suatu bug ditemukan, maka harus dilakukan koreksi terhadapnya. Van Vleck [VAN89]

memberikan tiga pertanyaan sederhana, dimana tiap teknisi software harus menanyakannya

terlebih dahulu sebelum membuat koreksi dan mengilangkan penyebab dari suatu bug:

1. Apakah penyebab bug dihasilkan lagi pada bagian lain dari program?

Dalam banyak situasi, defect program disebabkan oleh suatu pola logika yang salah yang

mungkin akan dihasilkan lagi di lain tempat.Pertimbangan eksplisit dari pola logika,

adalah adanya kemungkinan merupakan hasil di dalam penemuan errors yang lain.

Testing dan Implementasi Sistem

Sebelum koreksi dilakukan, source code (atau disain) harus dievaluasi untuk menilai

pasangan struktur data dan logika. Jika koreksi dilakukan pada bagian yang mempunyai tingkat keterikatan tinggi dalam program, harus memberikan perhatian khusus saat tiap perubahan dibuat.

3. Apa yang dapat dilakukan untuk mencegah terjadinya bug di awal?

Jika proses dikoreksi maka produk secara otomatis akan terkoreksi. Bug akan dapat

dihilangkan dari program saat ini dan akan dihilangkan dari semua program yang akan datang.

Testing dan Implementasi Sistem

5 P e r e n c a n a a n Testing

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 sekuensialisasi tes dan estimasi tes.

Ma ter i :

Obyektifitas Rencana Testing

Rencana Tes Berdasarkan pada Standar IEEE Hal-Hal yang Berhubungan dengan Rencana Tes Kerangka Rencana Tes Sederhana

Testing Terstruktur vs Testing Tidak Terstruktur Spesifikasi Tes Tingkat Tinggi vs Spesifikasi Tes Detil Berapa Banyak Tes Dinyatakan Cukup?

Sekuensialisasi Tes Teknik Estimasi Usaha Tes Faktor-Faktor Estimasi Estimasi Usaha Tes Penjadualan Usaha Tes

Testing dan Implementasi Sistem

“Walaupun programer, tester dan manajer pemrograman tahu bahwa kode harus didisain dan dites, pada kenyataannya, banyak yang tidak memperhatikan bahwa tes itu sendiri harus didisain dan dites – didisain oleh suatu proses yang tidak kurang dalam hal kepastian dan

pekendaliannya daripada yang digunakan untuk kode.”

Boris Beizer 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 jadual dan sumber daya tes, dan penilaian kesiapan sistem untuk diserahkan berupa coba-coba dalam suatu kondisi yang penuh dengan ketidakpastian, (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 . 1 O b y e k t i f i t a s R e n c a n a T e s t i n g

Obyektifitas utama dari rencana testing adalah:

Memfasilitasi tugas-tugas teknis dari testing, antara lain:

Meningkatkan cakupan tes: Daftar fitur, komponen, layar, pesan kesalahan,

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 pengecekan proses kerja akan menghindarkan dari kelalaian 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 meningkatkan

Testing dan Implementasi Sistem

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.

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 batasan: Tentang akurasi dan cakupan

testing – pembaca akan menunjukkan kekurangan dari rencana tes,

kesalahpahaman, dan kesalahan tes yang berpotensi lainnya di awal.

Ukuran dari pekerjaan testing: Mengkomunikasikan ukuran dari pekerjaan dengan 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 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.

Menyediakan struktur untuk pengorganisasian, penjadualan, dan

testing, antara lain :

pengaturan proses Mencapai persetujuan akan tugas-tugas tes: Secara spesifik mengidentifikasi apa yang akan (dan tidak akan) dilakukan oleh tester.

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 orang yang sama.

Organisasi: Mengidentifikasi siapa yang melakukan tes, bagaimana mereka akan

melakukan tes, dimana, kapan dan dengan sumber daya apa (hardware/software

khusus, manusia, dan lain-lain)

Koordinasi: Mendelegasikan tugas berdasarkan pada seksi-seksi dari rencana tes.

Meningkatkan akuntabilitas: Tester mengerti tugas mereka, membantu identifikasi

masalah staf atau rencana tes tertentu, bilamana terdapat bug yang terlewatkan dari

Testing dan Implementasi Sistem

5.2 Ren can a Tes Berdas arkan pad a

Dalam dokumen Modul testing dan implementasi sistem Kartika (Halaman 119-124)

Dokumen terkait