Sepintas lalu, sepertinya mencari kesalahan itu mudah. Tapi sebenarnya mencari kesalahan itu tidak semudah yang dipikirkan. Sebelum menyatakan sesuatu itu salah, kita harus tau apa yang benar. Untuk menyatakan sesuatu itu salah, kita juga harus teliti, karena kadang-kadang sesuatu yang terasa benar belum tentu benar dan sebaliknya sesuatu yang terlihat salah belum tentu salah, makanya perlu diuji untuk mengetahui kebenarannya (atau kesalahannya).
Aduh kalimatnya jadi agak sulit. Maksudnya gini, pekerjaan penguji perangkat lunak sekilas terasa mudah. Banyak orang yang anggap “tester program” itu kerjaan ga bergengsi. Padahal, jadi tester itu ga mudah, ga sekedar mencari kesalahan dalam program, tapi terutama harus tau dulu cara kerjanya biar tau gimana mencari kesalahannya. Dan kalau program itu menyangkut hajat hidup orang banyak, kita harus lebih hati-hati, kalau kita menyatakan suatu program lulus uji, dan dikemudian hari terjadi bencana gara-gara program itu, mungkin tester yang akan duluan ditanya, “kamu testingnya gimana sih?”. Untuk mengubah pandangan ga keren dari “tester” muncullah istilah Quality Assurance (emang kesannya lebih keren, tapi ya emang QA ga cuma test doang sih, tapi lebih dari itu).
Awalnya sih menyenangkan ketika kita bisa menemukan ada yang salah, tapi ketika semua terlihat berjalan dengan baik padahal kita tahu bahwa tidak semua berjalan dengan baik, rasanya mulai melelahkan. Dibutuhkan waktu dan ketelitian untuk mencari tahu apa yang tidak pada tempatnya. Walaupun sering kali, selain ketelitian tingkat tinggi, dibutuhkan juga keberuntungan atau ketidaksengajaan. Dalam mencari kesalahan juga harus kreatif, kita nggak bisa cuma mengetes hal-hal yang ada di dokumentasi/help program, karena pembuat program pasti sudah mengujinya, atau setidaknya orang yang membuat dokumentasi pasti sudah mencobanya untuk membuat screen capture. Pengetahuan sebagai pembuat program bisa membantu banyak untuk mencari tahu kesalahan dalam program.
Tantangan yang paling berat adalah mencari kesalahan program yang kita tidak kenali cara kerjanya secara lengkap. Pertama harus cari tahu dulu bagaimana menggunakannya. Ketika menggunakannya mungkin kita ketemu kesalahan, tapi kita ga bisa langsung buru-buru bilang bahwa itu emang salah, harus cek dan ricek dengan dokumentasinya, siapa tahu itu memang batasan program.
Seorang penguji program harus mencari tahu apa yang salah dan memiliki bukti yang lengkap untuk menyatakan bahwa ada yang salah dalam program. Dan untuk menyatakan suatu hal itu adalah kesalahan program seorang penguji harus bisa mereproduksi kesalahan tersebut untuk ditunjukkan kepada pemrogram agar dapat diperbaiki. Dalam kasus pengujian yang dilakukan oleh pemrogram itu sendiri, dia harus bisa melokalisasi kesalahan yang terjadi, karena kalau tidak hati-hati memperbaiki satu hal bisa mengakibatkan kesalahan ditempat lain.
Mencari kesalahan dalam program sama saja dengan memprogram, tidak sekedar program itu bisa dikompilasi, tapi juga harus diperhatikan logika programnya. Mencari kesalahan dalam logika program inilah yang lebih membutuhkan tenaga ekstra dan mungkin kadang membuat kening berkerut. Semakin kompleks dan canggih sebuah program, semakin sulit mencari kesalahannya. Kalau kita tahu program itu “buggy” tapi kita tidak bisa menunjukkan di mana kesalahannya, bos jadi tidak senang, katanya itu sama dengan “memancing tapi ga dapat ikan”. Well, untuk memancing butuh umpan dan waktu. Gak setiap hari kita bisa menemukan kesalahan dalam program, apalagi kalau program itu sudah dikembangkan sekitar 10 tahun sedangkan gue baru sekarang mengenalnya.
Untungnya, program yang gue uji ga seperti kisah-kisah yang di sini.
