Reveal asterix password

There is a trick for both Internet Explorer and Firefox that can help you reveal the passwords behind those asterisk or you can even simply see a list of all passwords saved by IE or Firefox in their program memory.

Reveal Asterisk Password in Internet Explorer

To reveal the hidden password behind asterisk in IE you need a utility called AsterWin IE that will show you the current password on your IE screen hidden behind asterisk. Just run the application when you are on a website’s login page and it will automatically scan and reveal the hidden password.

In case you want the list of all passwords saved by IE just use IE PassView which is another useful utility made by the creators of AsterWin IE.

Reveal Asterisk Password in Firefox

Revealing the hidden passwords in Firefox is pretty much simple. Just copy/paste the following javascript when in your address bar whenever you are on a site with a login form and it will display the password behind asterisk right away.









To get a list of all the passwords saved by Firefox just navigate to Tools >> Options and click the Security tab. In the security tab click the Show Passwords button to reveal a list of all hidden passwords.

Pretty much easy and yet very useful.

Belajar Ajax ga susah kok

Belajar Ajax dari Dasar

Ajax, kita tentu sudah sering mendengar kata-kata tersebut. Apalagi bagi Web Programmer, Ajax sudah menjadi teknologi yang wajib digunakan dalam membuat website moderen. Tapi sebenarnya apa sih Ajax itu? dan dari mana sebenarnya Ajax berasal? Mari kita bahas satu persatu.
Asal mula Ajax

Apa perbedaan antara aplikasi website dan aplikasi desktop pada komputer? Jawabannya hanya satu, aplikasi desktop lebih interaktif dan responsif dibanding aplikasi web. Jika anda pernah melihat aplikasi pada desktop, jika kita mengklik suatu tombol maka reaksi perubahannya akan langsung terlihat pada aplikasi tersebut yang membuat aplikasi desktop sangat interaktif. Tetapi pada website jika kita mengklik suatu tombol/link maka browser akan melakukan refresh pada browser dimana layar browser akan menjadi putih sesaat karena pada saat itu browser sedang meminta/merequest data dari server

Google Suggest merupakan aplikasi web pertama yang menggunakan Ajax. Istilah Ajax sendiri diperkenalkan oleh Jesse James Garrett

Hal itulah yang membuat aplikasi website menjadi kurang interaktif dan responsif dibanding aplikasi desktop. Ajax digunakan untuk memecahkan masalah tersebut, Ajax membuat aplikasi website menjadi lebih interaktif dan responsif seperti aplikasi desktop. Saat ini Ajax sudah menjadi teknologi yang wajib ada bagi website-website moderen (atau istilahnya Web 2.0).
Asal mula Ajax

Ajax merupakan kepanjangan dari Asynchronous JavaScript + XML dan bukan merupakan bahasa pemrograman baru tetapi suatu metode/teknik baru yang menggunakan teknologi yang telah ada. Ajax menggunakan teknologi lama yaitu Javascript yang melakukan request ke server untuk meminta data dalam bentuk Text/XML. Coba anda bandingkan diagram proses suatu website keserver pada website konvensional dan website yang menggunakan Ajax:
Sekarang bandingkan dengan website yang menggunakan Ajax:

Jika anda lihat pada website yang menggunakan Ajax, proses request ke server dilakukan oleh Javascript. Sehingga tampilan pada browser client tidak mengalami perubahan (refresh). Kemudian hasilnya akan dikirim oleh server dalam bentuk Text/XML dan ditampilkan dibrowser client

Bagian mana dari tampilan website yang akan berubah? Ajax menggunakan CSS untuk menentukan bagian mana dari website untuk diisi oleh tampilan baru yang baru saja diambil dari server.
Ajax menggunakan Javascript, jadi jika Javascript pada browser tidak aktif aplikasi Ajax anda tidak berfungsi. Karena itu gunakan aplikasi Ajax sebagai pendukung website anda, maksudnya disini anda membuat website biasa tanpa Ajax, setelah jadi baru anda menambahkan Ajax pada website anda. Jadi jika kemungkinan terburuk terjadi yaitu browser pengunjung tidak mengaktifkan Javascript, maka pengunjung masih dapat menikmati website anda.
Aplikasi Ajax

Pada aplikasi Javascript konvensional jika kita menginginkan data dari server kita menggunakan Form dan memanggilnya dengan method GET atau POST. Sehingga pengunjung perlu mengklik tombol dan kemudian halaman akan kerefresh untuk menampilkan hasil dari request tersebut.

Nah, kalau dengan Ajax, Javascript berkomunikasi langsung keserver dengan fungsi XMLHttpRequest. dengan XMLHttpRequest suatu halaman web dapat meminta data dari server dan menerima hasilnya tanpa perlu terjadi refresh pada halaman web tersebut. XMLHttpRequest telah disupport oleh IE 5 keatas, Safari 1.2 keatas, Mozilla Firefox keatas dan Opera 8 keatas.

Ajax merupakan penggabungan teknologi-teknologi berikut ini:

* Javascript
* HTML/XHTML
* XML
* CSS

Jadi jika anda belum menguasai salah satu dari teknologi tersebut saya sarankan anda pelajari terlebih dahulu sebelum meneruskan membaca artikel ini. Percaya sama saya, Ajax bukan sesuatu yang mudah untuk dipelajari, anda perlu memahami ke empat teknologi tersebut.
Contoh aplikasi Ajax

Langsung saja akan saya berikan contoh aplikasi Ajax, saya akan berikan contoh dan nanti akan saya jelaskan dibawahnya. Sekarang anda tuliskan kode dibawah ini dan simpan dengan nama coba.html

(html)
(head)
(title)Request file dengan Ajax(/title)
(script language = "javascript")
var XMLHttpRequestObject=false;
if (window.XMLHttpRequest) {
XMLHttpRequestObject = new XMLHttpRequest();
} else if (window.ActiveXObject) {
XMLHttpRequestObject = new ActiveXObject("Microsoft.XMLHttp");
}
function getdata(url,divhasil) {
if (XMLHttpRequestObject) {
var obj = document.getElementById(divhasil);
XMLHttpRequestObject.open("GET", url);
XMLHttpRequestObject.onreadystatechange = function() {
if (XMLHttpRequestObject.readyState == 4 &&

XMLHttpRequestObject.status == 200) {
obj.innerHTML = XMLHttpRequestObject.responseText;
}
}
XMLHttpRequestObject.send(null);
}
}
(/script)
(/head)
(body)
(h1)Mengambil data dari file HTML(/h1)
(form)
(input type="button" value="Tampilkan Data" onclick="getdata

('tampil.html','divhasil')")
(/form)
(div id="divhasil")
Isi dari tampil.html akan ditampilkan disini
(/div)
(/body)
(/html)

Sekarang buat file tampil.html dan isilah dengan kode berikut ini:

Text ini diambil dengan (strong)Ajax(/strong)

Sekarang lihat hasilnya.

Jika anda lihat hasilnya, dan anda klik tombol “Tampilkan Data” maka text dibawahnya akan berubah tanpa me refresh halaman, text tersebut diambil dari file tampil.html.

Kita memanggil fungsi getdata pada tombol tersebut serta mengirim url yang akan ditampilkan. Inilah kode yang digunakan untuk memanggil fungsi getdata:
(input type="button" value="Tampilkan Data" onclick="getdata('tampil.html','divhasil')")
Oke sekarang kita perlu membuat object XMLHttpRequest, objek ini wajib dipanggil jika kita ingin menggunakan Ajax. Untuk memanggilnya kita perlu menggunakan kode berikut ini:

var XMLHttpRequestObject=false;
if (window.XMLHttpRequest) {
XMLHttpRequestObject = new XMLHttpRequest();
} else if (window.ActiveXObject) {
XMLHttpRequestObject = new ActiveXObject("Microsoft.XMLHttp");
}

Pertama-tama kita set XMLHttpRequestObject=false ini untuk berjaga-jaga jika sebelumnya XMLHttpRequestObject sudah aktif maka kita non aktifkan lagi. Kemudian baru kita aktifkan lagi dengan membuat objek yang baru XMLHttpRequestObject = new XMLHttpRequest();. Perlu diingat bahwa Internet Explorer menggunakan ActiveX untuk membuat XMLHttpRequest, karena itu kita membuat kode XMLHttpRequestObject = new ActiveXObject("Microsoft.XMLHttp");

Oke setelah kita membuat objek XMLHttpRequest sekarang kita membuat fungsi untuk mengambil file dan menampilkannya. Disini kita membuat fungsi function getdata (url,divhasil), yang didalamnya terdapat XMLHttpRequestObject.open ("GET", url); yang berarti kita mengambil url dengan method get. Perlu diingat jika kita menggunakan method get kita perlu mengirimkan sesuatu keserver, karena kita tidak mengirim apa-apa maka kita kirimkan saja nilai kosong dengan kode: XMLHttpRequestObject.send(null);

XMLHttpRequestObject.onreadystatechange = function() merupakan sebuah fungsi dimana nanti kita akan memperoleh status dari request yang kita lakukan. XMLHttpRequestObject.readyState memiliki 4 status yaitu:

* 0 Request kita belum dibuat
* 1 Request kita sedang dalam proses (biasanya kita buat loading dengan ini)
* 2 Request kita sudah dikirim tapi hasil belum diterima
* 3 Request kita sedang diproses dikomputer klien
* 4 Request sudah sukses dikirim dan kita sudah sukses menerimanya

Sementara XMLHttpRequestObject.status merupakan status http standard. Jadi jika statusnya 200 berarti file html nya ada dan siap ditampilkan. Sehingga kita perlu mengecek kedua status tersebut dengan kode if (XMLHttpRequestObject.readyState == 4 && XMLHttpRequestObject.status == 200). Jika kedua statusnya oke, maka kita perlu menampilkannya dengan perintah obj.innerHTML = XMLHttpRequestObject.responseText. Dimana ini berarti kita menampilkannya di obj, sementara variabel obj telah kita isi dengan divhasil, ini kode ketika kita mengisi obj dengan divhasil, var obj = document.getElementById(divhasil).

Dan karena pada kode HTML kita memiliki tag div dengan id="divhasil", maka isi dari tampil.html akan ditampilkan didalam tag div tersebut. Bagaimana mudah bukan? atau malah bingung? Pelajari lagi dan pahami berulang- ulang, karena yang tadi baru dasar dari Ajax.

Jika kita ingin menambahkan loading ketika request sedang berlangsung maka kita perlu menambahkan if lagi untuk mengecek status dari XMLHttpRequestObject.readyState. Ubahlah kode coba.html menjadi:

(html)
(head)
(title)Request file dengan Ajax(/title)
(script language = "javascript")
var XMLHttpRequestObject=false;
if (window.XMLHttpRequest) {
XMLHttpRequestObject = new XMLHttpRequest();
} else if (window.ActiveXObject) {
XMLHttpRequestObject = new ActiveXObject("Microsoft.XMLHttp");
}
function getdata(url,divhasil) {
if (XMLHttpRequestObject) {
var obj = document.getElementById(divhasil);
XMLHttpRequestObject.open("GET", url);
XMLHttpRequestObject.onreadystatechange = function() {
if (XMLHttpRequestObject.readyState == 1) {
obj.innerHTML = "Loading";
}
if (XMLHttpRequestObject.readyState == 4 &&

XMLHttpRequestObject.status == 200) {
obj.innerHTML = XMLHttpRequestObject.responseText;
}
}
XMLHttpRequestObject.send(null);
}
}
(/script)
(/head)
(body)
(h1)Mengambil data dari file HTML(/h1)
(form)
(input type="button" value="Tampilkan Data" onclick="getdata

('tampil.html','divhasil')")
(/form)
(div id="divhasil")
Isi dari tampil.html akan ditampilkan disini
(/div)
(/body)
(/html)

Sekarang lihat hasilnya.

Bagaimana mudah bukan? Jika anda ingin menambilnya dari file php maka anda cukup mengganti tampil.html menjadi file php saja, cukup mudah. Pelajarilah dasarnya sebelum membuat aplikasi yang lebih canggih. Walaupun hanya dasarnya saja anda bisa mengembangkannya hingga menjadi aplikasi yang luar biasa. Perlu diingat karena kita mengambil data dari klien maka kemungkinan website kita untuk diserang menjadi lebih mudah karena kode Javascript kita terlihat dibrowser. Untuk itu berhati-hatilah dengan kode Javascript anda jangan tampilkan informasi rahasia pada kode Javascript anda.
Pada aplikasi web biasa ibaratnya kita memiliki sebuah ruangan dengan pintu besar yang harus kita kunci dan lindungi agar orang tidak masuk melalui pintu tersebut. Pada aplikasi Ajax selain memiliki pintu, ruangan tersebut juga memiliki banyak jendela untuk dimasuki, karena itu kita harus waspada.

Memahami Struktur Khas Proses Uji Perangkat Lunak

Dengan dan proyek perangkat lunak besar melanjutkan pembangunan sesuai struktur tim berikut
1) Tim Fitur Pemilik: Ini adalah sebuah tim tingkat atas dalam hirarki, yang secara langsung berinteraksi dengan pelanggan prospektif. Hal ini bertanggung jawab untuk teliti memahami kebutuhan pelanggan dan kelompok-kelompok mereka menjadi beberapa fitur. Berbagai anggota tim sedemikian mungkin menjadi pemilik beberapa fitur tersebut. Anggota tim mengambil inisiatif dan secara aktif karena berinteraksi dengan berbagai tim menjadi penting dalam memberikan arah yang diperlukan dalam mengembangkan fitur yang dimiliki oleh mereka.
2) Tim Antarmuka Pengguna: User Interface yang disebut UI pendek sangat signifikan bagi produk. Bahkan jika sebuah produk perangkat lunak memiliki serangkaian fitur yang sangat baik, namun Antarmuka Pengguna tidak efektif & mudah, produk ini ditakdirkan untuk gagal.
Oleh karena itu tim independen User Interface dibuat. Para anggota dari tim User Interface adalah spesialis dalam merancang User Interface untuk produk perangkat lunak dan memahami perbedaan antara User Interface yang baik dan yang satu miskin. Tujuan satu-satunya tim seperti User Interface adalah untuk melakukan riset ekstensif dalam User Interface.
Tim desain UI UI untuk produk atau fitur-fiturnya. Dalam langkah berikutnya tim UI berinteraksi dengan tim Pemilik Fitur untuk memberikan bentuk praktis untuk UI bersama-sama. hasil pertemuan tersebut dapat menjadi mungkin "Page desain" atau "maket" yang mengandung semua elemen dari UI seperti yang diharuskan dalam halaman. The maket sangat membantu dalam penyajian tampilan yang diinginkan atau penampilan halaman. navigasi Aktual antara berbagai halaman juga diperiksa selama pertemuan lintas fungsional tersebut.
3) Tim Pengembangan: Apakah dipercayakan tugas pengembangan Produk.
4) Tim Uji Perangkat Lunak: Apakah dipercayakan tugas pengujian produk.
ARUS PROSES ATAS:
1) Proyek Kick mulai: Para anggota tim fitur pemilik kick memulai proses dengan pengembangan dokumen desain di tingkat tinggi berlaku untuk semua fitur & sama dilepaskan untuk semua pihak.
2) Pelepasan Tingkat Tinggi Desain Dokumen: Selain dari dokumen desain tingkat tinggi yang disiapkan oleh pemilik fitur, desain dari halaman atau User Interface maket dilepaskan untuk semua pihak yang terkait untuk referensi oleh tim UI.
3) Pengembangan Perangkat Lunak: Coding fitur yang diinginkan dimulai oleh tim pengembangan sesuai dokumen dirilis.
4) Software Pengujian: pengujian yang menendang tim memulai kegiatan terkait pengujian dengan cara sebagai berikut:
($) Penyusunan Dokumen dengan Test Garis Besar: Dokumen ini menjelaskan rincian arus dari pengujian atau Skenario Multiple-Test diproyeksikan pada tingkat tinggi. Uji garis akan memiliki informasi singkat tentang apa yang perlu diperiksa pada titik selama arus.
Selain rincian arus, dokumen ini berisi garis besar uji matriks rinci menjelaskan semua persyaratan dari Dokumen Tingkat Tinggi Desain (HLD) ke arus uji. Dalam HLD sebuah ID yang unik khas dapat mengidentifikasi kebutuhan masing-masing. Tujuan dari matriks ini adalah untuk memastikan bahwa semua persyaratan telah diperiksa dengan teliti untuk kekurangan apapun.
($) Persiapan Uji Kasus: Setiap skenario pengujian lebih lanjut dikonversi menjadi kasus uji individu, yang berisi semua informasi yang rinci. Ini menentukan langkah-langkah yang tepat untuk navigasi, yang diinginkan data dan informasi rinci tentang apa yang perlu diperiksa. penjelasan rinci dalam Kasus Uji berguna terutama ketika orang-orang yang menulis kasus pengujian selain orang-orang akan mengeksekusi mereka.
($) Test Otomasi: Meskipun tidak wajib, otomatisasi tes adalah langkah opsional. Ini melibatkan otomatisasi uji kasus dirancang dengan bantuan beberapa alat otomatisasi, paling cocok dengan kebutuhan perusahaan.
($) Concurrent Kegiatan: Pengembangan & kerja pengujian dilakukan secara bersamaan. Tim pengembangan mendapatkan terlibat dalam tugas utama coding dari fitur yang diinginkan. Tim Pengembangan kadang-kadang melakukan semacam pengujian pada akhir mereka. Sementara itu, tim menyiapkan pengujian kasus uji untuk pengujian manual dan otomatisasi script untuk mengotomatisasi pelaksanaan uji dengan bantuan beberapa alat otomatisasi.
($) Produk Pengujian: Siklus pengujian dimulai ketika tim pengujian secara aktif memulai pengujian produk dan mulai penebangan bug dalam sistem repositori bug didefinisikan. Saat para pengembang yang terlibat dalam perbaikan dari bug.
Sebagai praktik terbaik, dua contoh aplikasi terpisah diselenggarakan. Satu contoh adalah diperuntukkan bagi tim pengujian dan yang kedua dimaksudkan untuk tim pengembang atau bug fixing tim. Namun kedua tim beroperasi pada tingkat kode yang sama.
($) Logging Bugs: Sebelum penebangan bug dalam sistem bug repositori, itu diverifikasi, apakah kita dapat mereproduksi dalam contoh dimaksudkan untuk para pengembang atau tidak. Jika bug tersebut direproduksi, itu diberikan kepada pengembang yang bersangkutan untuk memperbaiki diperlukan. Ketika bug tersebut tetap, maka kode memperbaiki diterapkan pada contoh pengembang, benar-benar diverifikasi dan kemudian diterapkan untuk contoh tim pengujian untuk pengujian regresi.
Namun jika bug tersebut tidak bisa direproduksi di contoh pengembang, itu dapat disimpulkan bahwa hal itu dapat menjadi masalah yang berhubungan dengan beberapa jenis aplikasi setup. Dalam kasus seperti pengembang berinteraksi dengan tim pengujian untuk memastikan apakah itu adalah bug asli yang memerlukan perubahan kode atau beberapa jenis aplikasi pengaturan masalah. masalah pengaturan aplikasi seperti ini cukup umum selama pengujian dari suite produk perangkat lunak erat terintegrasi.
($) Regresi Pengujian: Kode patch dilakukan & penguji mengulang pengujian dari awal. Dalam rangka untuk memperbaiki bug, sering menambal sistem dihindari. Sesuai dengan kebijakan terbaik untuk menambal bug, untuk putaran melibatkan beberapa pengujian, patch dari semua bug akumulasi antara dua putaran pengujian dilakukan sekali saja, itu bug yang tetap dan selalu siap untuk patch bersama. Ini juga tidak memiliki aturan keras & cepat. Pengecualian ada untuk bug, yang dianggap kritis & yang parah dapat menghambat pengujian dapat segera ditambal.
($) Sanity Pengujian: Setelah patch selesai, contoh aplikasi untuk menguji kewarasan dikenakan oleh tim pengembangan. Kemudian dilepaskan untuk putaran berikutnya melibatkan pengujian pelaksanaan semua kasus uji lagi. Ini mencakup pelaksanaan uji kasus yang terjadi untuk lulus di babak sebelumnya.
($) Menghentikan Operasi Pengujian: Dalam skenario pengujian beberapa ronde, sebuah keputusan penting harus diambil, apakah untuk melanjutkan ke babak berikutnya pengujian atau menghentikan ada itu sendiri. Keputusan penting untuk sebagian besar tergantung pada jumlah bug yang telah dicatat selama putaran sebelumnya dari pengujian. Dua faktor dapat membantu mengambil keputusan tersebut adalah:
1) pengujian perangkat lunak lebih lanjut dapat berhenti ketika tidak ada bug kritis segar yang terdeteksi & ketika tidak perlu merasa lebih lanjut untuk pengujian regresi.
2) pengujian lebih lanjut dapat berhenti ketika jumlah sangat kurang masalah kecil yang tersisa. Istilah "Kurang" sangat subjektif dan sangat tergantung pada aplikasi yang sedang diuji.
Ingat bahwa setelah kita mampu menunjukkan kemampuan kita untuk secara efektif memahami proses pengujian software, dunia akan terbuka untuk kami dengan banyak peluang pekerjaan pengujian Perangkat Lunak yang besar juga.

BUG

“Bug” dalam bahasa Inggris berarti kutu atau binatang kecil, merupakan istilah populer yang cukup menakutkan dalam pembuatan aplikasi, terutama karena efek kerusakan yang ditimbulkan terkadang tidaklah kecil. Bug merupakan kesalahan atau kerusakan program yang menyebabkan satu atau lebih fungsi tidak berjalan sebagaimana mestinya. Salah satu pencegahan bug adalah dengan melakukan testing pada aplikasi. Testing aplikasi merupakan suatu kegiatan untuk mengidentifikasikan keberhasilan, kelengkapan, keamanan, dan kualitas pada aplikasi yang bersangkutan. Karena itu, testing aplikasi merupakan kegiatan yang sangat penting sebelum Anda memperkenalkan aplikasi Anda pada masyarakat luas. Testing bertujuan untuk menemukan bug, testing merupakan proses membandingkan output nyata dengan out-put yang diharapkan. Sebuah bug menyebabkan kerusakan, walau demikian harus dimengerti bahwa tidak semua kerusakan disebabkan oleh bug. Agar tidak rancu dengan pengertian bug aplikasi, sebelum itu Anda perlu mengenal beberapa istilah kesalahan yang sering terjadi sewaktu aplikasi berjalan, antara lain:

1. Crash.
Yaitu saat sistem atau komponen komputer mengalami gangguan secara tiba-tiba. Aplikasi dapat menutup dengan sendirinya, atau untuk kasus yang lebih parah, dapat terjadi hang pada komputer yang menyebabkan Anda harus melakukan restart. Crash tidak selalu berasal dari bug aplikasi, crash dapat berasal dari permasalahan hardware, operating system, ataupun software lainnya. Tetapi, bug aplikasi dapat saja menyebabkan crash.

2. Anomaly.
Saat sebuah aplikasi menghasilkan sesuatu yang ganjil dan menyimpang dari dokumentasi operasional aplikasi tersebut, maka hal ini disebut anomaly. Hal ini bukan merupakan bug jika fungsi aplikasi berjalan dengan baik, hanya saja
tidak dibuat sesuai dengan dokumentasi atau harapan sebelumnya.

3. Fault.
Kesalahan yang terjadi karena kesalahan urutan langkah, proses, atau definisi data sehingga menyebabkan program melakukan proses yang tidak diantisipasi.Kesalahan ini dapat disebabkan karena kesalahan melakukan prosedur aplikasi.

4. Mistake.
Kegiatan yang dilakukan pengguna sehingga menyebabkan aplikasi mengeluarkan hasil yang salah. Istilah GIGO (Garbage In Garbage Out) menunjukkan bahwa output yang salah dapat disebabkan karena input yang salah. Kesalahan seperti ini bukan merupakan bug aplikasi. Walaupun demikian, aplikasi yang baik melakukan validasi input yang diperlukan untuk mencegah program mengeluarkan hasil dengan kesalahan yang fatal. Dapat diambil kesimpulan, bahwa tidak semua kesalahan yang terjadi berasal dari bug aplikasi. Terkadang kesalahan yang terjadi berada di luar kontrol aplikasi itu sendiri. Testing yang dilakukan tidak mungkin mencakup seluruh aspek seperti operating system, hardware, ataupun pengaruh software-software lainnya terhadap aplikasi. Walaupun untuk beberapa kasus, perlu dilakukan testing terhadap aspek-aspek tersebut. Tetapi hanya jika aplikasi yang Anda buat berhubungan erat dengan aspek tersebut. Testing sebaiknya sudah dilakukan sejak awal pembuatan aplikasi dan terus berlanjut, testing yang hanya dilakukan pada akhir development dapat berisiko besar. Terutama jika aplikasi yang dibuat memiliki skala yang cukup besar.

Sebagai contoh sederhana, Anda melakukan testing suatu aplikasi pada akhir development, kemudian Anda menemukan sebuah bug, yaitu salah satu field penting yang seharusnya memiliki tipe data string, ternyata memiliki tipe data numerik. Sekilas merupakan kesalahan yang sederhana. Tetapi bayangkan, jika seluruh modul atau form pada aplikasi yang menggunakan field tersebut terlanjur memperlakukan field tersebut sebagai numerik, maka Anda harus memeriksa ulang seluruh modul/form yang berhubungan dengan field tersebut. Dan jika perlu melakukan perubahan terhadapnya. Hal ini tentu tidak perlu terjadi jika sedari awal Anda telah melakukan testing dan menyadari kesalahan tersebut sebelum membuat lebih banyak form dan modul yang berhubungan dengan bug tersebut.

Panduan Proses Testing
Terdapat dua panduan utama untuk melakukan proses testing, yaitu:
1. Memeriksa bahwa aplikasi berfungsi sebagaimana mestinya. Misalnya Anda membuat aplikasi pendataan, pastikan bahwa Anda melakukan testing dengan mengisi seluruh field, dan data yang dimasukkan tersimpan dengan benar pada database.
2. Jika bug ditemukan dan telah diperbaiki, pastikan bahwa bagian-bagian lain dari aplikasi (sekalipun yang nampaknya tidak berhubungan dengan bug tersebut) masih berjalan dengan baik. Karena kadang tanpa disadari, perbaikan bug justru mendatangkan bug baru pada bagian yang lain.

Tahapan Testing
Terdapat cukup banyak pendekatan yang dilakukan untuk melakukan testing. Salah satu definisi testing adalah “sebuah proses yang melakukan pertanyaan terhadap sebuah produk untuk dinilai”, di mana “pertanyaan” merupakan segala sesuatu yang diberikan kepada produk sebagai pengujian.
Beberapa tahapan testing yang umum dilalui oleh aplikasi adalah sebagai berikut:

1. Unit/Component Testing.
Terbagi atas testing terhadap unit dan component. Unit testing merupakan proses testing, di mana Anda melakukan testing pada bagian basic dari kode program. Contohnya adalah memeriksa kode program pada event, procedure, dan function. Unit Testing meyakinkan bahwa masing-masing unit tersebut berjalan sebagaimana mestinya.Pada Unit Testing, Anda memeriksa bagian kode program secara terpisah dari bagian yang lain. Anda dapat langsung melakukan Unit Testing setiap kali sebuah kode unit (event, procedure, function) selesai dibuat. Anda dapat memeriksa kode unit dengan menjalankannya baris per baris untuk memastikan bahwa proses yang dilakukan berjalan sebagaimana yang Anda inginkan.

Termasuk di dalamnya adalah memeriksa masing-masing kondisi pada kode program. Sebagai contoh, kode program Anda memiliki statement If… Then… Else…., Anda perlu menyediakan dua set input untuk kondisi true maupun false dan memeriksa hasilnya masing-masing. Jika bagian kode program yang sedang Anda testing memanggil unit yang lain sebagai satu kesatuan, Anda masih dapat melakukan Unit Testing dengan menciptakan sebuah unit sederhana yang bertindak sebagai unit dummy. Metode ini dikenal dengan nama Stub. Jika bagian kode program yang sedang Anda testing perlu dipanggil oleh unit yang lain, Anda dapat menciptakan sebuah unit sederhana yang bertindak sebagai rutin pemanggil. Metode ini dikenal dengan nama Driver. Testing tambahan yang perlu Anda lakukan pada tahap ini adalah Component Testing.Meliputi testing pada fungsi-fungsi yang lebih kompleks yang tercakup menjadi suatu komponen, di mana fungsi-fungsi tersebut dapat dipecah menjadi unit-unit yang lebih kecil.

2. Integration Testing.
Setelah Anda melakukan Unit/Component Testing, langkah berikutnya adalah memeriksa bagaimana unit-unit tersebut bekerja sebagai suatu kombinasi, bukan lagi sebagai suatu unit yang individual. Sebagai contoh, Anda memiliki sebuah proses yang dikerjakan oleh dua function, di mana satu function menggunakan hasil output dari function yang lainnya. Kedua function ini telah berjalan dengan baik secara individu pada Unit Testing. Pada tahap Integration Testing, Anda memeriksa hasil dari interaksi kedua function tersebut, apakah bekerja sesuai dengan hasil yang diharapkan. Anda juga harus memastikan bahwa seluruh kondisi yang mungkin terjadi dari hasil interaksi antarunit tersebut menghasilkan output yang diharapkan.

3. System Testing.
Mencakup testing aplikasi yang telah selesai didevelop. Karena itu, aplikasi harus terlihat dan berfungsi sebagaimana mestinya terhadap end-user atau pengguna akhir. Untuk itu, testing dilakukan dengan menggunakan data yang menggambarkan data yang digunakan oleh pengguna sesungguhnya terhadap aplikasi. Jika aplikasi Anda di-develop untuk lingkungan yang besar,
Anda dapat melakukan testing pada dua komputer yang berbeda. Komputer yang Anda gunakan sebagai komputer testing harus terlebih dahulu dikonfigurasi hanya dengan:
a. Operating system yang dibutuhkan.
b. Driver yang diperlukan oleh aplikasi.
c. Aplikasi yang dites.
Dengan menggunakan konfi gurasi yang paling minimal dan sederhana, maka dapat membantu Anda untuk memastikan bahwa permasalahan yang timbul selama testing berlangsung adalah merupakan kesalahan aplikasi, dan bukan kesalahan yang berasal dari aplikasi atau software lain.

4. Acceptance Testing.
Seperti Integration Testing, Acceptance Testing juga meliputi testing keseluruhan aplikasi. Perbedaannya terletak pada siapa yang melakukan testing. Pada tahap ini, end-user yang terpilih melakukan testing terhadap fungsi-fungsi aplikasi dan melaporkan permasalahan yang ditemukan. Testing yang dilakukan merupakan simulasi penggunaan nyata dari aplikasi pada lingkungan yang sebenarnya. Proses ini merupakan salah satu tahap final sebelum pengguna menyetujui dan menerima penerapan sistem aplikasi yang
baru. Karena itu pada tahap ini sudah tidak difokuskan untuk mengangkat permasalahan kecil seperti kesalahan pengetikan, ataupun kosmetik aplikasi. Hal-hal minor seperti di atas sudah seharusnya ditangani selama Unit/Component Testing dan Integration Testing.

5. Regression Testing.
Merupakan bagian penting dari masing-masing tahap proses testing. Regression Testing mencakup pengujian ulang terhadap unit, component, proses, atau keseluruhan aplikasi setelah perbaikan suatu kesalahan dilakukan.Regression Testing memastikan permasalahan yang terjadi telah ditanggulangi, dan tidak terdapat permasalahan baru yang timbul sebagai efek perbaikan tersebut. Selain itu, tahap ini tidak hanya berguna untuk melakukan pengujian aplikasi, tetapi dapat juga digunakan untuk melakukan pemantauan kualitas dari output yang dihasilkan. Sebagai contoh, Regression Testing memantau ukuran file, waktu yang dibutuhkan untuk melakukan suatu tes, waktu yang dibutuhkan untuk melakukan kompilasi, dan lain sebagainya.

Keamanan
Aspek keamanan (security) menjadi salah satu topik paling hangat semenjak teknologi komputer berkembang pesat, sehingga untuk aplikasi yang memiliki akses terbuka dan mengharuskan tingkat keamanan yang tinggi, testing aplikasi harus mempertimbangkan pengujian keamanan aplikasi tersebut. Sebagai contoh adalah sebuah aplikasi e-commerce yang mengizinkan transaksi melalui kartu kredit. Cukup banyak terjadi kasus pemalsuan credit card dengan memanfaatkan kelemahan aplikasi e-commerce.Testing pada aplikasi internet atau jaringan, memerlukan pengetahuan tersendiri untuk memeriksa apakah terdapat kelemahan aplikasi, beberapa teknik yang digunakan oleh para hacker seperti SQL Injection, XSS, dan lain-lain harus diuji coba terhadap aplikasi Anda.

Untuk aspek keamanan ini, ada kalanya Anda memerlukan konsultan yang kompeten dan mengikuti perkembangan yang terjadi dalam hal keamanan data pada jaringan dan Internet. Konsultan akan memberikan langkah-langkah pencegahan yang perlu diambil, hal ini kadang tidak hanya melibatkan sisi programming aplikasi, tetapi juga dapat melibatkan sisi administrator sistem, mencakup konfigurasi operating system, web server, firewall, router, dan lain sebagainya. Tidak terbatas hanya untuk aplikasi internet seperti e-commerce, aplikasi intranet atau client server sekalipun harus memperhatikan sisi keamanan ini. Terlebih karena aplikasi stand-alone saat ini umumnya semakin ditinggalkan (kecuali untuk alasan-alasan tertentu).Walaupun masalah keamanan merupakan topik tersendiri, tetapi secara nyata sangat berhubungan erat dengan aplikasi. Sebagai contoh, sejak ditemukan teknik SQL Injection maka aplikasi web yang tidak mempedulikan masalah ini akan mendapatkan label aplikasi dengan lubang keamanan dan berisiko tinggi, atau memiliki bug.

Dokumentasi Testing
Dalam segala kegiatan, dokumentasi merupakan hal yang vital. Mungkin Anda pernah menangani aplikasi yang sebelumnya telah dikerjakan oleh orang lain, tetapi tidak menemukan sedikit pun dokumentasi mengenai aplikasi tersebut. Hal itu tentu akan merepotkan Anda. Testing termasuk salah satu kegiatan yang perlu didokumentasikan, bahkan merupakan suatu ide yang baik untuk menuliskan rencana testing sebelum memulai proses testing itu sendiri. Rencana testing tersebut akan menjelaskan semua fungsi-fungsi aplikasi yang diminta, hal ini dapat dijadikan patokan untuk penjadwalan testing. Untuk setiap proses testing, rencana Anda sebaiknya melakukan spesifi kasi untuk:
1. Masing-masing item yang dites.
2. Bagaimana item-item tersebut dites.
3. Hasil yang diharapkan.
4. Kriteria keberhasilan.

Dokumen Anda juga mengidentifikasikan saat Anda memutuskan untuk tidak melakukan testing terhadap fitur tertentu, dan menjelaskan alasannya. Selain itu, Anda perlu menjelaskan lingkungan testing yang digunakan.

Program Testing
Testing tidak selalu harus dilakukan secara manual. Anda dapat menulis sebuah program kecil untuk melakukan testing dengan memberikan input data pada proses unit, component, process, atau aplikasi yang sedang Anda test. Apakah tidak membuang-buang waktu untuk membuat sebuah program khusus untuk melakukan testing? Hal ini menjadi relatif tergantung aplikasi Anda. Terutama Anda harus mempertimbangkan frekuensi kebutuhan aplikasi Anda untuk melakukan Regression Testing.Anda dapat menggunakan kembali program testing tersebut setiap kali dilakukan Regression Testing, dengan demikian justru akan menghemat banyak waktu yang Anda keluarkan untuk melakukan testing.

Sertifikasi?
Sudah umum terjadi bahwa penilaian terhadap sesuatu sering didukung oleh sertifikasi. Sebagai contoh, bukankah terdapat sertifikasi seperti TOEFL untuk kemampuan bahasa inggris, atau sertifi kasisertifi kasi yang dikeluarkan Microsoft seperti MCAD, MSCE, MCSD. Bagaimana dengan sertifikasi testing? Walaupun sertifikasi testing aplikasi masih menjadi perdebatan, sudah terdapat beberapa sertifi kasi, seperti CSQE yang ditawarkan oleh America Society for Quality, CSTE/CSQA oleh Quality Assurance Institute, atau ISTQB oleh International Software Testing Qualifi cation Board. Bagaimanapun, saat ini belum terdapat sertifikasi yang benar-benar dapat diterima oleh berbagai aplikasi yang memiliki variasi dan keunikan masing-masing, yang menunjukkan bahwa lahan testing aplikasi belum siap untuk sertifikasi umum dan dapat diterima oleh aplikasi dan kebutuhan apa saja. Sertifikasi mungkin merupakan suatu bentuk penghargaan, tetapi dalam membuat suatu aplikasi, penghargaan yang paling tinggi datang dari end-user yang menggunakan aplikasi Anda. Kepuasan mereka adalah “sertifikasi” tidak tertulis yang menjadi barometer keberhasilan aplikasi Anda. Dengan melakukan testing aplikasi sejak awal, Anda telah melangkah untuk menciptakan keberhasilan aplikasi.

ERROR CODE

“ERROR” adalah sebuah kata yang terdengar cukup menakutkan di dunia pemrograman. Programer adalah orang yang akan dilirik dengan alis terangkat jika terjadi kesalahan pada sebuah aplikasi pada saat digunakan. Untuk menghindari hal tersebut, Anda perlu mengenal dan memperbaiki semua jenis kesalahan pada program.

Hampir tidak ada aplikasi yang berjalan sempurna sebelum melewati berbagai rentetan kesalahan, semakin besar aplikasi yang dibuat, semakin banyak kesalahan yang dapat timbul. Sukar dibayangkan jika Anda dapat mengetikkan ratusan baris kode program tanpa ditemukan kesalahan pada saat dijalankan atau dikompilasi untuk pertama kalinya.

Syntax Error

Kesalahan yang paling sering ditemukan pada saat membuat program adalah kesalahan sintaks atau Syntax Error, dimana perintah atau statemen yang diketikkan menyalahi aturan pengkodean yang dimiliki oleh bahasa pemrograman yang Anda gunakan.

Sebuah bahasa pemrograman memiliki aturan pengkodean tersendiri yang harus dipatuhi, sebagai contoh pada bahasa pemrograman Pascal/Delphi, setiap statemen diwajibkan diakhiri dengan tanda titik koma (;). Jika Anda tidak menuliskannya, program akan menampilkan pesan Syntax Error pada saat dijalankan.

Setiap bahasa pemrograman memiliki keyword, yaitu perintah-perintah baku yang digunakan. Sebagai contoh, keyword yang umum adalah kondisi if, perulangan for atau while, penulisan fungsi dan lambang aritmatika seperti modulus, pangkat, dan lain-lain. Kesalahan penulisan keyword juga merupakan Syntax Error.

Kesalahan penulisan parameter pada sebuah function/procedure juga termasuk dalam kategori Syntax Error, misalnya jika function yang Anda gunakan memerlukan parameter sementara Anda lupa menuliskan parameter tersebut.

Syntax Error merupakan jenis kesalahan yang paling sering ditemui, tetapi juga pada umumnya paling mudah untuk ditanggulangi. Syntax Error cukup mudah diketahui dan diperbaiki jika bahasa pemrograman yang Anda gunakan menunjukkan baris kesalahan dengan tepat, dan menampilkan pesan kesalahan yang benar.

Pada beberapa bahasa pemrograman, disediakan fasilitas Auto Syntax Check, dimana muncul sebuah pesan peringatan ketika Anda mengetikkan sintaks yang salah.

Run-time Error

Jenis kesalahan Run-time Error terjadi ketika kode program melakukan sesuatu yang tidak dimungkinkan. Contohnya pada saat sebuah aplikasi mencoba mengakses file yang tidak ada, atau terjadi kesalahan alokasi memory.

Terkadang Run-time Error terjadi karena berbagai aspek dan tidak selalu karena kesalahan pemrograman, sebagai contoh jika Anda sengaja menghapus beberapa file penting yang digunakan oleh suatu aplikasi, maka terdapat kemungkinan akan terjadi Run-time Error pada saat aplikasi tersebut dijalankan.

Walaupun demikian, pencegahan semaksimal mungkin dengan memberikan validasi dan pesan yang user-friendly saat terjadi kesalahan pada aplikasi, akan sangat membantu untuk mengetahui mengapa aplikasi tidak berjalan dengan semestinya.

Logical Error

Logical Error merupakan jenis kesalahan yang cukup sulit untuk ditemukan penyebabnya. Karena aplikasi yang mengandung Logical Error berjalan tanpa pesan kesalahan, tetapi mengeluarkan hasil yang tidak diharapkan, misalnya jika aplikasi Anda menghasilkan perhitungan yang salah.

Logical Error baru dapat diketahui setelah Anda melakukan testing dan meninjau hasilnya. Logical Error dapat diperbaiki dengan memeriksa alur program dan nilai variabel yang dihasilkan.

Programer = Pencari Bug?


Sebuah error pada aplikasi disebut dengan istilah bug, atau dalam Bahasa Inggris berarti kutu atau binatang kecil. Konon istilah bug muncul karena ditemukannya binatang kecil yang menyebabkan kerusakan pada sebuah komputer tabung pada tahun 1945.

Bug aplikasi terdapat pada kode program, yang dapat mengganggu kenyamanan pengguna aplikasi Anda. Pada tingkat tertentu, keberadaan bug cukup memberikan efek yang besar.

Anda mungkin belum melupakan saat dimana orang ramai membicarakan “Y2K Bug” atau bug tahun 2000, atau munculnya istilah “Blue screen of Death” pada sistem operasi Windows, atau “Kernel Panic” pada sistem operasi Linux, semua contoh tersebut menunjukkan sebuah bug serius dapat mengakibatkan dampak negatif yang cukup besar.

Proses mencari penyebab bug disebut dengan debug, yang juga merupakan tugas programer setelah menerima laporan bug. Walaupun demikian, jangan menjadikan pekerjaan Anda sebagai pencari bug, Untuk itu hanya ada satu cara, minimalkan bug pada aplikasi yang Anda buat.

Apa yang harus Anda lakukan untuk menghindari jenis-jenis kesalahan yang telah disebutkan di atas? Bisa jadi tidak ada program yang sempurna, tetapi selalu ada cara untuk mengatasi atau menghindari kesalahan semaksimal mungkin.

Selalu Deklarasikan Variabel

Syntax Error, bahkan Logical Error, mungkin terjadi jika terdapat penulisan variabel yang salah. Sebaiknya Anda mendeklarasikan variabel yang Anda gunakan walaupun bisa jadi bahasa pemrograman yang Anda gunakan mengijinkan untuk tidak melakukan deklarasi variabel.

Visual Basic merupakan salah satu bahasa pemrograman yang mengijinkan penggunaan variabel tanpa deklarasi, walaupun demikian disarankan Anda menggunakan deklarasi variabel. Hal tersebut akan memperkecil kesalahan penulisan variabel.

Masih dengan contoh Visual Basic, Anda dapat menambahkan perintah Option Explicit pada program untuk mencegah kesalahan tulis pada variabel, jika terdapat variabel yang belum dideklarasikan, maka Visual Basic akan menampilkan pesan kesalahan.

Anda sebaiknya memiliki suatu skema standard untuk pemberian nama variabel dan konsisten dengan penggunaannya. Contohnya berikan nama variabel diawali dengan huruf s jika bertipe data string, misalnya sResult, sTemp, dan lain-lain.

Pada Visual Basic maupun beberapa bahasa pemrograman lain yang berorientasi object, kita dapat mendeklarasikan variabel dengan tipe data object. Terdapat berbagai jenis macam object yang dikenal, dan sebaiknya Anda menuliskannya dengan lengkap object yang dimaksud. Misalnya object ListBox, Label, dan lain-lain.

Gunakan Variabel Lokal

Sangat disarankan agar Anda selalu menggunakan variabel lokal. Salah satu manfaatnya adalah jika terjadi kesalahan program (terutama Logical Error), maka penyebab kesalahan dan solusinya akan lebih mudah ditemukan. Hal ini dikarenakan variabel lokal memiliki ruang lingkup penggunaan yang lebih kecil dibandingkan variabel global, yang dapat diakses oleh procedure yang mana saja.

Penggunaan variabel global, sering menimbulkan kerancuan dan memperbesar kemungkinan terjadinya kesalahan tanpa disadari.

Kenali Jenis Bug

Bug yang timbul pada sebuah aplikasi memiliki karateristik. Karena itu selalu baca dan perhatikan baik-baik pesan kesalahan yang timbul. Beberapa jenis bug berdasarkan karakteristiknya adalah sebagai berikut:

1. Divide By Zero.
Jika pada sebuah pembagian, pembagi bernilai 0, maka program akan terhenti dan mengalami error.

2. Infinite Loop.
Pengertian loop adalah perulangan, yang sering digunakan dalam teknik pemrograman. Penggunaan loop yang salah dapat mengakibatkan program menjalankan sebuah procedure tanpa akhir.

3. Arithmatic overflow or Underflow.
Overflow terjadi saat sebuah perhitungan menghasilkan nilai yang lebih besar daripada nilai yang dapat ditampung oleh media/variabel penyimpan. Sementara underflow merupakan kebalikannya. Pada perhitungan aritmatik, hal ini sering ditemukan dan menjadi masalah.

4. Exceeding Array Bounds.
Array merupakan variabel berdimensi yang memiliki indeks. Saat program mengakses indeks diluar array yang ditentukan, maka akan mengakibatkan error.

5. Access Violation.
Hal yang terjadi saat sebuah proses mencoba melewati batas yang diijinkan oleh sistem. Misalnya menulis sebuah nilai pada alamat memory, segmen, atau media yang diproteksi.

6. Memory Leak.
Penggunaan memory yang tidak diinginkan, dapat terjadi karena program gagal melepaskan memory yang sudah tidak digunakan.

7. Stack Overflow or Underflow.
Stack merupakan struktur data dengan prinsip LIFO (Last In First Out), pada program Anda dapat mengimplementasikan logika stack untuk suatu tujuan. Tetapi jika stack melebihi atau dibawah nilai yang diijinkan oleh program, maka akan timbul kesalahan Stack Overflow/Underflow.

8. Buffer Overflow.
Buffer merupakan tempat penyimpanan sementara dalam teknik pemrograman. Buffer Overflow terjadi jika Anda menyimpan terlalu banyak data yang tidak dapat ditampung oleh buffer yang disediakan.

9. Deadlock.
Merupakan suatu kondisi dimana dua atau lebih proses saling menunggu satu sama lain untuk menyelesaikan prosesnya, dan tidak satupun dari proses tersebut yang selesai. Problem deadlock sering ditemukan pada multiprocessing.

10. Off By One Error.
Merupakan istilah untuk menggambarkan perulangan yang terlalu banyak atau terlalu sedikit. Misalnya perulangan yang dikehendaki adalah lima kali, tetapi kenyataan yang terjadi aplikasi mengulang proses tersebut sebanyak empat kali atau enam kali. Kesalahan ini pada umumnya terjadi karena kesalahan logika penulisan kode pada proses perulangan.

Berikan Komentar

Jangan kuatir kode program Anda dipenuhi oleh komentar. Karena akan lebih mudah bagi Anda untuk mempelajari lagi kode-kode program yang pernah Anda buat dengan membaca komentar.

Dengan mengerti kode program dengan baik, maka akan menjadi lebih mudah jika pada suatu saat terdapat Logical Error yang membutuhkan analisa ulang kode program.

Gunakan Log File

Informasi proses yang dijalankan aplikasi dan tersimpan pada sebuah log file (dapat berupa file text atau table) dapat menjadi informasi yang sangat berguna untuk menganalisa bug yang mungkin terjadi. Terutama informasi yang menjelaskan apa yang terjadi sebelum, selama, dan sesudah bug terjadi.

Untuk menghindari log file yang terlalu besar, Anda dapat memisahkan log file terbagi menjadi log untuk komponen-komponen utama pada aplikasi. Jangan lupa untuk selalu mencatat waktu (timestamp) pada setiap record. Anda dapat menghapus atau melakukan backup pada log file secara periodik.

Validasi

Tidak semua orang mematuhi aturan yang Anda terapkan pada aplikasi, karena itu Anda harus melakukan validasi untuk data yang dimasukkan oleh pengguna. Misalnya pada suatu form pendaftaran, Anda sebaiknya melakukan validasi untuk input yang tidak boleh kosong (mandatory/required fields), melakukan pembatasan karakter, dan validasi huruf/angka yang diperlukan.

Mengenal Environment

Saat Anda mengetikkan kode program, menjalankannya, atau melakukan debug pada program, Anda berada pada environment yang berbeda-beda. Terdapat 3 environment yang umum dikenal, yaitu:

1. Design Time.
Aplikasi yang Anda kerjakan dilakukan pada saat design time.

2. Run Time.
Saat menjalankan aplikasi.

3. Break Mode.
Environment saat Anda melakukan proses debug atau melihat kode program saat program tersebut dijalankan, Anda dapat melihat alur program dan perubahan nilai pada variabel, sehingga Anda dapat menelusuri kesalahan yang terjadi. Break Mode terletak diantara Design Time dan Run Time.

Lebih Jauh Mengenal Break Mode

Break Mode merupakan environment favorit programer untuk melacak kesalahan program atau dikenal dengan proses debug, terkadang memerlukan kesabaran dan ketelitian super tinggi, tetapi no pain no gain, bukan?

Dengan menjalankan Break Mode, aplikasi Anda akan dijalankan bertahap dari satu proses ke proses selanjutnya, Anda juga dapat menghentikan proses Break Mode setelah mendapatkan informasi yang cukup dalam proses debug.

Dalam menganalisa kesalahan di dalam kode program yang sangat panjang, akan sangat melelahkan jika Anda melakukan debug per-baris program dari awal hingga akhir. Untuk itu fasilitas breakpoint sangat penting untuk keperluan debug. Breakpoint mengijinkan Anda menandai baris dimana proses debug dimulai.

Posisi breakpoint tidak dapat ditempatkan pada baris:

1. Compiler Directive.
2. Deklarasi Variabel.
3. Baris Konstanta.
4. Baris yang kosong atau berisi komentar.

Pada saat memasuki Break Mode, umumnya terdapat beberapa instruksi yang dapat Anda gunakan untuk melakukan proses debug:

1. Step Into.
Menjalankan kode program baris per baris. Setelah satu baris dieksekusi, maka cursor akan berpindah pada baris dibawahnya. Jika baris yang dieksekusi merupakan suatu procedure, maka proses debug akan berpindah pada procedure tersebut dan akan menjalankan kode program didalamnya.

Dengan eksekusi per-baris ini, Anda dapat memantau nilai-nilai variabel yang dihasilkan, umumnya pada sebuah jendela terpisah yang menampilkan nilai-nilai variabel saat ini.

Setiap kali Anda mengeksekusi baris program, maka program akan dijalankan pada environment Run Time, dan kembali pada Break Mode saat selesai menjalankan baris tersebut.

2. Step Over.
Pada prinsipnya Step Over sama dengan Step Into. Hal yang membedakan hanyalah saat pemanggilan sebuah procedure. Jika pada Step Into, proses debug akan memasuki procedure yang dipanggil dan mengeksekusi kode program didalamnya baris demi baris, maka Step Over menjalankan procedure tersebut tanpa memperlihatkan baris program didalamnya.

Step Over dilakukan jika Anda hanya ingin melakukan proses debug pada satu level, atau jika Anda yakin procedure yang dipanggil telah berjalan dengan baik dan tidak memerlukan proses debug per-baris.

Step Over dan Step Into dapat digunakan bergantian tergantung kebutuhan Anda dalam menganalisa kode program.

3. Step Out.
Jika Anda telah berada pada suatu procedure dan ingin kembali pada baris dimana procedure tersebut dipanggil, maka gunakanlah Step Out. Step Out akan menjalankan semua baris program yang tersisa pada procedure tersebut, dan kembali pada Break Mode saat keluar dari procedure yang bersangkutan.

4. Run To Cursor.
Anda dapat menentukan baris selanjutnya dimana Anda ingin memulai proses debug yang baru. Proses ini mirip dengan breakpoint, hanya Anda tidak perlu menandai baris tersebut terlebih dahulu, tetapi langsung mengarahkan eksekusi program pada posisi tersebut.

Layar Penolong Saat Break Mode

Melakukan proses debug pada Break Mode tidak akan menghasilkan sesuatu yang signifikan jika Anda tidak mengetahui apa saja yang terjadi pada variabel-variabel yang dieksekusi. Untuk itu Anda memerlukan layar penolong, yang dapat dikategorikan sebagai berikut:

1. Layar Immediate.
Jika layar ini diaktifkan, Anda dapat mengetikkan variabel atau perhitungan untuk melihat nilainya. Anda bahkan dapat mengubah nilai variabel yang sedang berjalan sehingga mempengaruhi proses debug selanjutnya.

Anda dapat mengetikkan object debug pada baris program sehingga menampilkan nilai variabel yang ingin Anda monitor pada Layar Immediate, contoh perintah object debug adalah debug.print.

Pada Visual Basic 6.0, Anda dapat mengaktifkan Layar Immediate dengan memilih menu View – Immediate Window.

2. Layar Local.
Layar Local akan menampilkan seluruh nilai variabel pada procedure yang sedang aktif/dijalankan pada saat Break Mode, sehingga Anda dapat memonitor perubahannya tanpa perlu mengetikkan masing-masing variabel atau menggunakan object debug seperti pada Layar Immediate.

Selain itu, Layar Local juga menampilkan hirarki object dan property yang terdapat pada form yang aktif.

Pada Visual Basic 6.0, Anda dapat mengaktifkan Layar Local dengan memilih menu View – Locals Window.

3. Layar Watch.
Digunakan untuk melihat nilai variabel pada konteks yang telah ditentukan, misalnya pada procedure tertentu. Anda harus terlebih dahulu mendefinisikan variabel atau expression yang ingin Anda tampilkan. Expression adalah sebuah instruksi untuk menjalankan sesuatu yang menghasilkan sebuah nilai, x = 1 adalah contoh sebuah expression sederhana.

Terkadang Anda memerlukan Watch jika Anda memiliki nama variabel yang sama tetapi terletak pada procedure/konteks yang berbeda. Layar Watch juga sangat berguna karena Anda dapat menentukan expression, dimana pada saat kondisi nilai expression tersebut terpenuhi atau berubah, maka program akan berada pada Break Mode.

Pada Visual Basic 6.0, Anda dapat mengaktifkan Layar Watch dengan memilih menu View – Watch Window. Untuk menambahkan variabel/expression, pilih menu Debug – Add Watch, atau Debug – Quick Watch.

4. Layar Call Stack.
Sering terjadi pada saat melakukan proses debug, Anda tersesat dan kehilangan alur karena terlalu banyak procedure dan modul yang dieksekusi. Pada saat ini Layar Call Stack sangat diperlukan.

Call Stack menunjukkan alur proses debug dengan menampilkan procedure yang dieksekusi secara berurutan. Sehingga Anda dapat mengetahui procedure pemanggil dan procedure yang dipanggil.

Pada Visual Basic 6.0, Anda dapat mengaktifkan Layar Call Stack dengan memilih menu View – Call Stack.

Langkah Pelaksanaan

Anda telah meminimalkan kesalahan, Anda telah mengenal dan memiliki tools untuk menanggulangi kesalahan, tetapi masih terdapat bug yang ditemukan dan harus ditanggulangi. Berikut adalah langkah mengatasi bug:

1. Kenali Keberadaan Bug.
Programer yang berpengalaman sering telah dapat mengira-ngira penyebab terjadinya bug, beberapa proses yang rumit pada aplikasi dapat menyebabkan kesalahan saat digunakan oleh user. Contohnya saat aplikasi membutuhkan data input dengan format tertentu, tetapi user menyediakan data input dengan format yang salah.

Jika respon aplikasi adalah dengan menampilkan pesan kesalahan dan menghentikan proses, kesalahan akan dapat lebih mudah diperbaiki. Sedangkan kesalahan yang diketahui karena hasil yang tidak diinginkan tidak sesuai dengan hasil yang diharapkan, tetapi aplikasi tetap berjalan dengan baik justru akan lebih sulit diperbaiki.

Tujuan dari langkah ini adalah mengenali penyebab bug, dengan menganalisa dalam kondisi apa bug terjadi, maka akan lebih mudah untuk melangkah ke tahap selanjutnya.

2. Memisahkan Kode Program yang Mengandung Bug.
Setelah menemukan penyebab dan kondisi yang menghasilkan bug, Anda dapat memisahkan kode program yang bermasalah tersebut untuk diperiksa. Langkah ini memerlukan testing yang berulang-ulang untuk memastikan kode program yang bermasalah.

Lakukan testing secara berurutan, misalnya apakah input sudah benar, terbaca dengan benar, diproses dengan benar, dan seterusnya.

Langkah ini akan lebih mudah jika Anda membuat aplikasi dengan konsep pemrograman modular yang membagi-bagi program yang besar ke dalam sub modul atau procedure yang terpisah.

Jika terdapat suatu procedure yang menerima input dengan benar tetapi menghasilkan output yang salah, maka dapat dipastikan letak bug terdapat pada procedure tersebut.

3. Identifikasi Penyebab Bug.
Setelah menemukan lokasi kode program yang mengandung bug, langkah selanjutnya adalah mengidentifikasi penyebab bug. Pemahaman yang baik akan ruang lingkup aplikasi tersebut adalah kunci sukses mencari sumber bug.

Hal yang cukup berbahaya adalah jika Anda kurang memahami alur aplikasi dan mengubah kode program untuk memperbaiki bug yang ada, tetapi ternyata menciptakan bug yang lain.

4. Memperbaiki Bug.
Dengan mengidentifikasi sumber bug dengan tepat, mungkin akan timbul beberapa langkah perbaikan bug, pilihlah yang terbaik dan tidak mengganggu proses lainnya. Terkadang Anda dapat menemukan bug lain yang belum dilaporkan, eliminasi semua bug yang mungkin muncul.

5. Testing.
Setelah bug diperbaiki, adakan testing dengan tujuan memastikan apakah bug telah dapat ditanggulangi dan tidak muncul lagi, dan apakah perbaikan yang dilakukan tidak memiliki efek yang tidak diinginkan.

Basmi Sebelum Dilaporkan

Percaya atau tidak, ada beberapa pengguna aplikasi yang cukup kreatif menyikapi bug dengan cara sendiri dan memiliki resep khusus dengan mempelajari pola dan karakteristik aplikasi, sehingga bug dapat dihindari dengan melakukan langkah-langkah tertentu.

Contohnya ada aplikasi yang tidak dapat berjalan saat aplikasi tertentu aktif pada saat bersamaan, atau aplikasi yang baru berjalan baik pada resolusi layar tertentu. Ada baiknya Anda memperbaiki bug yang Anda temukan dan melakukan update pada pengguna, walaupun bug tersebut tidak dilaporkan.

Hal ini tentu akan menambah kredibilitas Anda, dan yang terpenting, aplikasi Anda akan menjadi lebih nyaman bagi pengguna.