Pengertian Sistem Testing

System testing adalah pengujian yang dilakukan terhadap

keseluruhan sistem (secara lengkap) dan sistem yang telah
terintegrasi untuk mengevaluasi apakah sistem yang dibuat
telah sesuai dengan kebutuhan pengguna.

System testing merupakan bagian dari black-box testing,

yang tidak membutuhkan pengetahuan tentang kode dan
logika pemrograman

 Menurut Hetzel 1973:

Testing adalah proses pemantapan kepercayaan akan
kinerja program atau sistem sebagaimana yang diharapkan.

 Menurut Myers 1979:

Testing adalah proses eksekusi program atau sistem secara
intens untuk menemuk

 Menurut Hetzel 1983 (Revisi):

Testing adalah tiap aktivitas yang digunakan untuk dapat
melakukan evaluasi suatu atribut atau kemampuan dari
program atau sistem dan menentukan apakah telah
memenuhi kebutuhan atau hasil yang diharapkan.

 Menurut Standar ANSI/IEEE 1059:

Testing adalah proses menganalisa suatu entitas software
untuk mendeteksi perbedaan antara kondisi yang ada
dengan kondisi yang diinginkan (defects / errors / bugs) dan
Kesalahan dalam sebuah kegiatan testing bukanlah sebuah
error atau pun bug tetapi merupakan sebuah hasil yang
tidak diharapakan sesuai dengan spesifikasi dari
permintaan customer. Dalam artian hal yang sedang terjadi
tidak sama dengan hal yang diharapkan.
Nama Testing Difinisi Cirri – cirri Contoh

Recovery testing jika ada suatu produk Recover test akan Program update keuangan
megeluarkan melihat gagal atau online tiba – tiba log off
error,produk itu akan tidaknya prosedur semua aktifitas kemudian
melakukan recovery untuk recover seluruh seluruh file
file. master corrupted kemudian
dapat backup

Security Testing test untuk Mengusahakan untuk  Menguji dengan

memastikan membuat sistem yang ekripsi
pengamanan sudah minimal lama untuk pengamanan
baik dibobol password
 Mengenalkan pada
sistem virus dsb.

Performance Testing untuk mengukur  Melakukan tes

performa sistem yang dengan
dibangun, pengukuran
menentukan dan evaluasi
kecepatan atau jaringan
efektivitas. program
computer,
perangkat
lunak atau
perangkat
 waktu respon
kepada sistem
(user request)
 jumlah waktu
proses CPU
(time required)
 TESTING APLIKASI SERVER

Performance Testing :
Dapat dilakukan secara paralel dengan volume dan stress testing karena yang ingin diketahui
adalah bagaimana kinerja sistem pada semua kondisi load, baik itu jam-jam sibuk atau
sebaliknya.
Biasanya terkait dengan Response time dan rata-rata proses yang dapat diselesaikan dalam
berbagai macam konfigurasi dan kondisi pemrosesan.
Harus mencakup semua konfigurasi hardware dan sistem (laptop VS desktop, LAN vs WAN,
dll).

 Data recovery,

Kemampuan data Recovery dan system restart dapat menghemat waktu dan uang
ketika terjadi kegagalan pada sistem Produksi.
Ada bermacam-macam level teknologi RAID (Redundant Array of Inexpensive Disks)
yang merupakan framework untuk menyebarkan data di beberapa database atau file
server dan memastikan data dapat direcovery jika terjadi kegagalan pada salah satu
server. Yang perlu dites adalah recovery options untuk sistem RAID kita ketika
memonitor performa sistem tersebut.

Data Security Testing

 Menguji akses kontrol untuk tool yang dipergunakan pihak ketiga.

 Menguji prosedur untuk kontrol akses ke tabel database tertentu.
 Menguji pemakaian password yang terenkripsi / transmisi data.
 Menguji pemakaian user name bayangan (shadow user name) untuk user yang memiliki
akses write dan read.

Pengujian Aplikasi Server

1. Volume Testing
2. Stress Testing
3. Performance Testing
4. Data Recovery Testing
5. Data Backup and Restore Testing
6. Data Security Testing

Volume Testing
Menemukan kelemahan sistem selama melakukan pemrosesan data dalam jumlah yang besar
dalam periode waktu yang singkat.
Tujuan: meyakinkan bahwa sistem tetap melakukan pemrosesan data anatar batasan fisik dan
batasan logik.
Contoh:
Mengujikan proses antar server dan antar partisi hardisik pd satu server.

Stress Testing
Tujuan: mengetahui kemampuan sistem dalam melakukan transaksi selama periode waktu
puncak proses. Contoh periode puncak: ketika penolakan proses login on-line setelah sistem
down atau pada kasus batch, pengiriman batch proses dalam jumlah yg besar dilakukan setelah
sistem down.
Contoh: Melakukan login ke server ketika sejumlah besar workstation melakukan proses
menjalankan perintah sql database.

Performance Testing
Dilakukan secara paralel dengan Volume dan Stress
testing untuk mengetahui unjuk kerja sistem (waktu
respon, throughput rate) pada beberapa kondisi
proses dan konfigurasi.
Dilakukan pada semua konfigurasi sistem perangkat
keras dan lunak.

 Mis.: pd aplikasi Client-Server diujikan pd kondisi korporate ataupun lingkungan sendiri

(LAN vs. WAN, Laptop vs.Desktop)

 Menguji sistem dengan hubungannya sistem ke lain pada server yg sama.

Data Recovery Testing

Investigasi dampak kehilangan data melalui proses recovery ketika terjadi kegagalan proses.
Penting dilakukan karena data yg disimpan di server dapat dikonfigurasi dengan berbagai cara.
Kehilangan Data terjadi akibat kegagalan sistem, hardisk rusak, peghapusan yg tidak sengaja,
kecelakaan, virus dan pencuri.

Data Backup and Restore

Testing
Dilakukan untuk melihat prosedur back-up dan recovery.
Diakukan dengan mensimulasikan beberapa kesalahan untuk menguji proses backup dan
recovery.
Pengujian dilakukan terhadap strategi backup: frekuensi , medium, waktu, mekanisme backup
(manual/ otomatis), personal, ? Berapa lama backup akan disimpan.
Switching antara live dan backup server ketika terjadi kerusakan (load log transaction pada back-
up kemudian melaku recovery).

Data Security Testing

Privilege access terhadap database diujikan pada beberapa user yang tidak memiliki privilege
access ke database.
Shutdown database engine melalui operating system (dengan beberapa perintah OS) yg dapat
mematikan
aplikasi database.

Debuging
1. Sistem Testing (pengujian)
Pengujian perangkat lunak (bahasa Inggris: software
testing) merupakan suatu investigasi yang dilakukan
untuk mendapatkan informasi mengenai kualitas dari
produk atau layanan yang sedang diuji (under
test).Pengujian perangkat lunak juga memberikan
pandangan mengenai perangkat lunak secara obyektif
dan independen, yang bermanfaat dalam operasional
bisnis untuk memahami tingkat risiko pada
implementasinya. Teknik-teknik pengujian mencakup,
namun tidak terbatas pada, proses mengeksekusi suatu
bagian program atau keseluruhan aplikasi dengan tujuan
untuk menemukan bug perangkat lunak (kesalahan atau
cacat lainnya).
2. Dua tipe produk perangkat lunak
 Produk Generik : Sistem stand-alone standar yang
diproduksi oleh organisasi pengembang dan dijual ke
pasar terbuka ke siapapun yang membelinya. Biasa
disebut sebagai software sbrink-wrapped. Contoh :
pengolah kata (word processor).
 Produk pesanan (yang disesuaikan) : Sistem yang
dipesan oleh pelanggan tertentu. Dikembangkan khusus
bagi pelanggan oleh kontraktor perangkat lunak. Contoh
: Sistem untuk mendukung proses bisnis tertentu dan
sistem kontrol lalu lintas udara.
Perbedaan penting antara tipe-tipe perangkat lunak :
1. Pada produk generik, organisasi yang mengembangkan
perangkat lunak mengontrol spesifikasi perangkat lunak.
2. Pada produk pesanan, spesifikasi biasanya
dikembangkan dan dikontrol oleh organisasi yang
membeli perangkat lunak tersebut.
3. Tujuan dilakukannya pengujian system,
Pengujian Sekali program dibuat, pengujian program
dimulai. Proses pengujian berfokus pada logika internal
software, memastikan bahwa semua pernyataan sudah
diuji, dan pada eksternal fungsional, yaitu mengarahkan
pengujian untuk menemukan kesalahan – kesalahan dan
memastikan bahwa input yang dibatasi akan
memberikan hasil aktual yang sesuai dengan hasil yang
dibutuhkan.
Pemeliharaan Software akan mengalami perubahan
setelah disampaikan kepada pelanggan (perkecualian
yang mungkin adalah software yang dilekatkan).
Perubahan akan terjadi karena kesalahan – kesalahan
ditentukan, karena software harus disesuaikan untuk
mengakomodasi perubahan – perubahan di dalam
lingkungan eksternalnya (contohnya perubahan yang
dibutuhkan sebagai akibat dari perangkat peripheral
atau sistem operasi yang baru), atau karena pelanggan
membutuhkan perkembangan fungsional atau unjuk
kerja. Pemeliharaan software mengaplikasikan lagi
setiap fase program sebelumnya dan tidak membuat
yang baru lagi.
Tujuan dari pengujian ini adalah diharapkan dengan
minimal tenaga dan waktu untuk menemukan berbagai
 potensi kesalahan dan cacat.Harus didasarkan pada
kebutuhan berbagai tahap pengembangan, desain dan
dokumen lain atau program yang dirancang untuk
menguji struktur internal, dan menggunakan contoh-
contoh ini untuk menjalankan program untuk
mendeteksi kesalahan.Pengujian sistem informasi harus
mencakup pengujian perangkat lunak, pengujian
perangkat keras dan pengujian jaringan.pengujian
Hardware, jaringan pengujian berdasarkan indikator
kinerja spesifik yang akan, digunakan di sini, pengujian
lebih jauh adalah pengujian perangkat lunak.
Sistem pengujian untuk memastikan kualitas dan
keandalan sistem langkah kunci dalam proses
pengembangan sistem adalah analisis sistematis pada
desain sistem dan pelaksanaan review akhir.
4. Perbedaan Verifikasi ,
5. Verifikasi adalah proses pemeriksaan apakah logika
operasional model (program komputer) sesuai dengan
logika diagram alur. Kalimat sederhananya, apakah ada
kesalahan dalam program? (Hoover dan Perry, 1989);
verifikasi adalah pemeriksaan apakah program komputer
simulasi berjalan sesuai dengan yang diinginkan, dengan
pemeriksaan program komputer. Verifikasi memeriksa
penerjemahan model simulasi konseptual (diagram alur
dan asumsi) ke dalam bahasa pemrograman secara
benar (Law dan Kelton, 1991) .
6. Validasi adalah proses penentuan apakah model, sebagai
konseptualisasi atau abstraksi, merupakan representasi
berarti dan akurat dari sistem nyata? (Hoover dan Perry,
 1989); validasi adalah penentuan apakah mode
konseptual simulasi (sebagai tandingan program
komputer) adalah representasi akurat dari sistem nyata
yang sedang dimodelkan (Law dan Kelton, 1991).
7. Debugging adalah sebuah metode yang dilakukan oleh
para pemrogram dan pengembang perangkat lunak
untuk mencari dan mengurangi bug, atau kerusakan di
dalam sebuah program komputer atau perangkat keras
sehingga perangkat tersebut bekerja sesuai dengan
harapan. Debugging cenderung lebih rumit ketika
beberapa subsistem lainnya terikat dengan ketat
dengannya, mengingat sebuah perubahan di satu sisi,
mungkin dapat menyebabkan munculnya bug lain di
dalam subsistem lainnya.

Performace Testing adalah teknik pengujian non-fungsional dilakukan untuk

menentukan parameter sistem dalam hal respon dan stabilitas dalam beban
aplikasi/website. pengujian kinerja mengukur atribut kualitas sistem, seperti
skalabilitas, kendala dan penggunaan sumber daya.

Fokus dari Performace Testing antara lain

 Speed : Menentukan apakah respon aplikasi cepat atau lambat
 Scalability : Menentukan beban pengguna maksimum aplikasi.
 Stability : Menentukan apakah aplikasi tersebut stabil di bawah beban yang
bervariasi
 Reability : Menentukan cara menghandle aplikasi apabila ada beban yang
berat
Jenis Performance Testing
 Load Testing : untuk memeriksa kemampuan dari aplikasi dalam melakukan
load aplikasi / website. gunanya agar mengatahui beban dari aplikasi / website
ke database / server sehingga resource yang digunakan tidak terlalu berat
 Stress testing : untuk memeriksa kemampuan dari aplikasi dalam menerima
trafic dari luar, gunanya agar aplikasi/website tidak down saatnya banyak user
yang mengakses aplikasi / website tersebut.
 Endurance Testing : untuk menentukan parameter sistem di bawah beban yang
diharapkan terus menerus. Selama Endurance Testing penggunaan memori
dipantau untuk mendeteksi kebocoran memori atau masalah kinerja lainnya.
Tujuan utama adalah untuk menemukan kinerja sistem dalam penggunaan
berkelanjutan.
 Spike testing : pengujian Spike dilakukan dengan meningkatkan jumlah
pengguna tiba-tiba dengan jumlah yang sangat besar dan mengukur kinerja
sistem. Tujuan utama adalah untuk menentukan apakah sistem akan mampu
mempertahankan beban kerja.


Jenis Permasalahan Performance Aplikasi

 Long Load time - Aplikasi/website tidak mungkin untuk melakukan loading di
atas satu menit, load time harus di bawah 10 detik jika memungkinkan.
 Poor scalability - Performance aplikasi bisa dibilang gagal apabila aplikasi
tersebut tidak dapat menampung beban yang sangat berat, sehingga aplikasi itu
bisa "down", maka dari itu performance testing harus dilakukan untuk
memastikan aplikasi dapat menangani jumlah diantisipasi pengguna.
 Bottlenecking - Kemacetan yang penghalang dalam sistem yang menurunkan
kinerja sistem secara keseluruhan. Bottlenecking adalah ketika salah coding
kesalahan atau masalah hardware menyebabkan penurunan throughput bawah
beban tertentu.

Performance Testing Process

  Identify your testing environment - Memahami rincian konfigurasi hardware,
software dan jaringan yang digunakan selama pengujian sebelum Anda memulai
proses pengujian. Ini akan membantu penguji membuat tes yang lebih efisien. Ini
juga akan membantu mengidentifikasi kemungkinan hambatan pada saat testing
 Identify the performance acceptance criteria - Hal ini juga diperlukan untuk
mengidentifikasi kriteria keberhasilan proyek di luar tujuan dan kendala. Penguji
harus menetapkan kriteria kinerja dan tujuan karena sering spesifikasi proyek tidak
akan mencakup cukup berbagai tolok ukur kinerja.
 Plan & design performance tests - Membuat test plan untuk mengidentifikasi
semua pengujian yang akan di lakukan
 Configuring the test environment - Mempersiapkan lingkungan pengujian sebelum
eksekusi. Juga, mengatur alat dan sumber daya lainnya.
 Implement test design - Membuat Scenario test sesuai dengan design
 Run the tests - Eksekusi test
 Analyze, tune and retest - Melakukan analis dari hasil test, untuk melihat apakah
ada peningkatan atau penurunan kinerja aplikasi. Sehingga dapat menentukan apa
yang harus ditingkatan dari sebuah aplikasi
Performance Testing Tools
 Jmeter
 Open STA
 Load Runner
 Web Load

Security Testing adalah teknik pengujian untuk menentukan jika sistem informasi melindungi
data dan mempertahankan fungsi sebagaimana dimaksud. Dengan melakukan pengujian
keamanan, Security Testing tidak menjamin bahwa sistem aman tetapi penting untuk
menyertakan keamanan pengujian sebagai bagian dari proses pengujian. Hal ini juga bertujuan
di memverifikasi 6 prinsip-prinsip dasar sebagai berikut:
 Kerahasiaan
 Integritas
 Otentikasi
 Otorisasi
 Ketersediaan
 Bebas-penyangkalan
Contoh
Jejak keamanan di aplikasi berbasis web yang melibatkan langkah-langkah yang kompleks dan
berpikir kreatif tetapi, attimes tes sederhana seperti di bawah ini dapat membantu mengekspos
risiko keamanan paling parah. Berikut adalah tes keamanan sangat dasar yang siapa pun dapat
melakukan pada aplikasi web:
1. Login ke aplikasi web menggunakan user dan password yang sah.
2. Keluar dari aplikasi web.
3. Klik tombol kembali browser. Pastikan jika Anda diminta untuk login lagi atau jika Anda
dapat kembali ke halaman login lagi.
Proses pengujian

Empat besar fase keamanan pengujian adalah sebagai berikut.

 Foot Printing
 Scanning
 Enumeration
 Exploitation

Debugging
Debugging bukan merupakan pengujian, namun merupakan konsekuensi dari pengujian yang berhasil.
Jika sebuah kasus uji berhasil menemukan kesalahan, maka proses debugging bertujuan untuk
menghilangkan kesalahan tersebut.

Debugging merupakan proses yang sulit untuk dilakukan karena adanya beberapa karakteristik bug
seperti:

 Gejala dan penyebab dari bug bisa saja sangat jauh, gejala dapat muncul pada bagian tertentu
dari program dan penyebabnya bisa saja berada pada bagian lain yang sangat jauh dari
tempat munculnya gejala

 Gejala dapat hilang ketika kesalahan yang lain diperbaiki

 Gejala dapat ditimbulkan oleh sesuatu yang tidak salah (mis. pembulatan yang tidak akurat)

 Gejala dapat disebabkan oleh kesalahan manusia yang sulit untuk ditelusuri

 Gejala dapat disebabkan oleh masalah timing

 Kemungkinan sulit untuk memproduksi kondisi input secara akurat

 Gejala dapat terjadi tiba-tiba

 Gejala dapat disebabkan oleh sesuatu yang didistribusikan melewati sejumlah tugas yang
bekerja pada prosesor yang berbeda-beda

Terdapat tiga jenis pendekatan debugging antara lain:

1. Brute Force

Merupakan teknik yang paling sering digunakan dan paling tidak efisien dalam mengisolasi penyebab
kesalahan. Dengan prinsip “biarkan komputer menemukan kesalahan”, maka seluruh sumber daya
komputer digunakan dengan tujuan untuk menemukan penyebab kesalahan

2. Backtracking

Merupakan pendekatan yang dimulai dari penemuan gejala kemudian menelusuri balik hingga ke
penyebab

3. Cause Elimination

Dimanifestasikan oleh induksi atau deduksi dan menggunakan konsep partisi biner. Data yang
berhubungan dengan kesalahan yang muncul dikumpulkan untuk mengisolasi penyebab. Kemudian
dibuat sebuah hipotesis dan data digunakan untuk membuktikan hipotesis tersebut. Daftar
serangkaian penyebab yang mungkin dibuat dan dilakukan pengujian untuk mengeliminasi penyeba-
penyebab tersebut. Jika pengujian menunjukkan kebenaran hipotesis untuk suatu penyebab, maka
data diperbaiki untuk mengisolasi bug
Sekali bug ditemukan, bug harus diperbaiki. Namun, perbaikan pada bug dapat memunculkan
kesalahan lain, maka ada beberapa pertimbangan sebelum bug dihilangkan antara lain:

Apakah penyebab bug ada pada bagian lain dari program?

Apakah “bug yang lain” mungkin terjadi pada saat perbaikan dilakukan?

Apakah yang telah dilakukan untuk mencegah bug pada tempat pertama?

DEBUGGING

Debugging adalah sebuah metode yang dilakukan oleh para pemrogram dan pengembang perangkat
lunak untuk mencari dan mengurangi bug, atau kerusakan di dalam sebuah program
komputer atau perangkat keras sehingga perangkat tersebut bekerja sesuai dengan
harapan. Debugging cenderung lebih rumit ketika beberapa subsistem lainnya terikat dengan ketat
dengannya, mengingat sebuah perubahan di satu sisi, mungkin dapat menyebabkan
munculnya bug lain di dalam subsistem lainnya.

Bug dengan terjemahan langsung ke bahasa Indonesia adalah serangga atau kutu. Bug merupakan
suatu kesalahan desain pada suatu perangkat keras komputer atau perangkat lunak komputer yang
menyebabkan peralatan atau program itu tidak berfungsi semestinya. Bug umumnya lebih umum
dalam dunia perangkat lunak dibandingkan dengan perangkat keras.

Kenapa dinamakan bug?

Tahun 1945 sewaktu ukuran komputer masih sebesar kamar, pihak militer Amerika
Serikat menggunakan komputer yang bernama “Mark 1”. Suatu hari komputer ini tidak berfungsi
dengan semestinya, setelah komputer itu diperiksa ternyata ada suatu bagian perangkat keras di
mana terdapat serangga yang tersangkut. Setelah serangga itu diangkat dari perangkat keras,
komputer dapat berfungsi dengan baik. Maka sejak saat itu kata bug lekat dengan masalah-masalah
pada komputer. Debugging adalah proses menghilangkan bug dari suatu program.

Pengujian perangkat lunak adalah proses yang dapat direncanakan dan ditentukan secara sistematis.
Desain test case dapat dilakukan, strategi dapat ditentukan, dan hasil dapat dievaluasi berdasarkan
harapan-harapan yang ditentukan sebelumnya.

Debugging terjadi sebagai akibat dari pengujian yang berhasil. Jika test case mengungkap kesalahan,
maka debugging adalah proses yang menghasilkan penghilangan kesalahan. Perekayasa perangkat
lunak yang mengevaluasi hasil suatu pengujian sering dihadapkan pada indikasi “simtomatis” dari
suatu masalah pernagkat lunak, yaitu bahwa manisfestasi eksternaldari kesalahan dan penyebab
internal kesalahan dapat tidak memiliki hubungan yang jelas satu dengan lainnya. Proses mental yang
dipahami secara buruk yang menghubungkan sebuah symptom dengan suatu penyebab disebut
debugging.

Proses Debugging
Debugging bukan merupakan pengujian, tetapi selalu terjadi sebagai bagian akibat dari pengujian.
Proses debungging dimulai dengan eksekusi terhadap suatu test case. Hasilnya dinilai, dan ditemukan
kurangnya hubungan antara harapan dan yang sesungguhnya. Dalam banyak kasus, data yang tidak
berkaitan merupakan gejala dari suatu penyebab pokok tetapi masih tersembunyi, sehingga perlu ada
koreksi kesalahan.

Proses debugging akan selalu memiliki salah satu dari dua hasil akhir berikut:

1. Penyebab akan ditemukan, dikoreksi, dan dihilangkan, atau

2. Penyebab tidak akan ditemukan.

Dalam kasus yang terakhir, orang yang melakukan debugging mungkin mencurigai suatu penyebab,
mendesainsuatu test case untuk membantu kecurigaannya, dan bekerja untuk koreksi kesalahan
dengan gaya yang iterative.

Beberapa karakteristik bug memberi kunci :

1. Gejala dan penyebab dapat jauh secara geografis, dimana gejala dapat muncul didalam satu
bagian dari suatu program, sementara penyebab dapat ditempatkan pada suatu sisi yang
terlepas jauh.

2. Gejala dapat hilang (kadang-kadang) ketika kesalahan yang lain dibetulkan.

3. Gejala dapat benar-benar disebabkan oleh sesuatu yang tidak salah (misalnya pembulatan
yang tidak akurat).

4. Simpton dapat disebabkan oleh kesalahan manusia yang tidak dapat dengan mudah
ditelusuri.

5. Gejala dapat merupakan hasil dari masalah timing, dan bukan dari masalah pemrosesan.

6. Mungkin sulit untuk mereproduksi kondisi input secara akurat (misalnya aplikasi real time
dimana pengurutan input tidak ditentukan).

7. Gejala dapat sebentar-sebentar. Hal ini sangat umum pada system yang embedded yang
merangkai perangkat lunak dan perangkat keras yang tidak mungkin dilepaskan.

8. Gejala dapat berhubungan dengan penyebab yang didistribusikan melewati sejumlah tugas
yang bekerja pada prosesor yang berbeda.

Selama debugging, kita menemukan kesalahan-kesalahan mulai dari gangguan yang halus (missal
format output yang tidak betul) sampai katrastropis (misalnya kegagalan system yang menyebabkan
kerusakan fisik atau ekonomis).
Sebagai akibat dari peningkatan keslahan, jumlah tekanan untuk menemukan kesalahan juga
bertambah. Sering kali tekanan memaksa seorang pengembang perangkat lunak untuk membetulkan
keslahan dan pada saat yang sama memunculkan lagi dua kesalahan baru.

Pertimbangan Psikologis

Sayangnya muncul banyak bukti bahwa kekuatan debugging adalah sifat bawaan manusia. Banyak
orang yang cakap dalam hal ini, sementara banyak juga yang tidak. Menanggapi aspek manusia dari
debugging. Shneiderman [SHN80] menyatakan :

Debugging merupakan salah satu dari berbagai bagian pemrograman yang membuat lebih frustasi.
Debugging memiliki elemen pemecahan masalah atau pengganggu otak, yang bersama dengan
penghindaran kesadaran bahwa Anda melakukan suatu kesalahan. Kekhawatiran yang meningkat dan
keengganan untuk menerima, kesalahan akan meningkatkan kesulitan tugas. Sayangnya, ada keluhan
yang sangat mendalam mengenai pembebasan dan pengurangan ketegangan ketika pada akhirnya
bug ……… dikoreksi.

Meskipun mungkin sulit untuk mempelajari debugging, sejumlah pendekatan terhadap masalah
tersebut dapat diusulkan. Kita akan melihat dalam sub bab selanjutnya.

Pendekatan-pendekatan Debugging

Tanpa memperhatikan pendekatan yang diambil, debugging memiliki satu sasaran yang diabaikan,
untuk menemukan dan mengkoreksi penyebab kesalahan perangkat lunak. Sasaran tersebut
direalisasi dengan suatu kombinasi evaluasi yang sistematis, intuisi, dan keberuntungan.

Bradley (BRA85) menggambarkan pendekatan Debugging dengan cara berikut :

Debugging adalah sebuah aplikasi langsung dari metodekeilmuan yang telah dikembangkan selama
2500 tahun. Dasar dari debugging adalah meletakkan sumber-sumber masalah (penyebab) dengan
partisi biner melalui hipotesis kerja yang memperkirakan nilai-nilai baru yang akan diuji.

Ambillah contoh non-perangkat lunak sederhana, yaitu :

Lampu dirumah saya tidak bekerja. Bila tidak ada yang bekerja didalam rumah itu, penyebabnya tentu
pada pemutus rangkaian utama atau sebab dari luar. Saya melihat sekeliling untuk melihat apakah
lampu para tetangga juga mati. Saya memasukkan lampu yang dicurigai kedalam soket yang bekerja
dan menyelidiki lampu rangkaian yang dicurigai. Begitulah berbagai pilihan hipotesa dan pengujian.

Secara umum, tiga kategoti pendekatan debugging dapat diusulkan (MYE79) :

1. 1. Gaya yang kasar (Brute force)

Kategori debugging brute force mungkin merupakan yang paling umum dan metode yang paling
efisien untuk mengisolasi penyebab kesalahan perangkat lunak. Kita mengaplikasikan metode
debugging brute force bila semua yang lain telah gagal. Dengan menggunakan filosofi ”biarkan
komputer menemukan kesalahan”, tempat sampah memori dipakai, penelusuran runtime dilakukan,
dan program dibebani dengan statemen WRITE. Kita mengharapkan bahwa dimanapun didalam rawa
informasi yang diproduksi, kita akan menemukan suatu kunci yang akan membawa kita kepada
penyebab kesalahan. Meskipun banyaknya informasi yang dihasilkan pada akhirnya akan membawa
kita meraih sukses, lebih sering dia menyebabkan kita menghambur-hamburkan usaha dan waktu.
Kita harus memikirkannya terlebih dahulu.

1. 2. Penelusuran balik (backtracking)

Backtracking adalah pendekatan debugging yang sangat umum yang dapat digunakan secara sukses
didalam program yang kecil. Mulai pada sisi dimana suatu gejala diungkap, kode sumber ditelusuri
balik (secara manual) samapai sisi penyebab ditemukan. Sayangnya, bila jumlah baris sumber
bertambah, maka jumlah jalur balik potensial dapat sangat banyak.

1. 3. Eliminasi penyebab

Cause elimination dimanisfestasikan oleh induksi atau deduksi serta mengawali konsep partisi biner.
Data yang berhubungan dengan kejadian kesalahan dikumpulkan untuk mengisolasi penyebab
potensial. Hipotesis penyebab dibuat dan data digunakan untuk membuktikan penolakan hipotesis
tersebut. Sebagai alternatif, daftar semua penyebab yang mungkin dikembangkan dan dilakukan
pengujian untuk mengeliminasi masing-masing kesalahan. Jika pengujian awal menunjukkan bahwa
suatu hipotesis penyebab memberikan gambaran hasil yang jelas, maka data itu disaring sebagai
usaha untuk mengisolasi bug.

Masing-masing pendekatan debugging tersebut dapat ditambah dengan piranti debugging. Kita dapat
mengaplikasikan berbagai kompiler debugging yang luas, bantuan debugging yang dinamis (tracer),
generator test case, ruang sisa memori dan peta cross-reference. Namun piranti bukanlah pengganti
bagi evaluasi yang berhati-hati yang didasarkan atas dokumen desain perangkat lunak yang lengkap
dan kode sumber yang jelas.

Sekali bug ditemukan, bug harus dibetulkan. Tetapi seperti telah kita catat, koreksi terhadap suatu
bug dapat memunculkan kesalahan lain sehingga lebih banyak merugikan daripada menguntungkan.

Van Vleck (FAN89) mengusulkan tiga pertanyaan sederhana yang harus diajukan kepada perekayasa
perangkat lunak sebelum melakukan koreksi yang menghilangkan penyebab suatu bug, yaitu :

1. 1. Apakah penyebab bug direproduksi didalam bagian lain program tersebut?

Dalam berbagai situasi, kesalahan program disebabkan oleh sebuah contoh logika yang keliru yang
dapat dibuat ulang ditempat lain. Pertimbangan eksplisit dari contoh logika tersebut akan
menghasilkan penemuan kesalahan yang lain.

1. 2. Apa ”bug selanjutnya,” yang akan dimunculkan oleh perbaikan yang akan dibuat?
Sebelum koreksi dibuat, kode sumber (atau lebih baik,desain) harus dievaluasi untuk memperkirakan
pemasangan logika dan struktur data. Bila koreksi akan dilakukan pada bagian program yang akan
dirangkai, maka harus ada perhatian khusus bila banyak perubahan dilakukan.

1. 3. Apa yang dapat kita lakukan untuk menghindari bug ini didalam tempat pertama?

Pertanyaan ini merupakan langkah pertama untuk membangun pendekatan jaminan kualitas
perangkat lunak statistik. Bila kita mengkoreksi proses dan produk, bug akan dihilangkan dari
program yang ada dan dapat dieliminasi dari semua program selanjutnya.