Testing itu Seni

Ketika metode dan tools testing bukan segalanya. Kolaborasi kreativitas dan logika umpama mahakarya sebuah seni yang harus dimiliki seorang tester, menjadi kunci utama dalam melakukan pengujian aplikasi.

Apa itu testing ?

Testing secara bahasa adalah pengujian. Tentu yang diuji adalah sebuah objek, dan yang menguji adalah subjek. Untuk case yang saya bahas dalam artikel ini ialah testing didunia IT (Software Development). Kenapa dibutuhkan pengujian dalam pengembangan software?. Jawaban sederhananya kita engga pengen software yang kita bakal jual ke user ada error, bug, atau fitur-fitur yang kurang sesuai ekspetasi. Aplikasi setidaknya sudah mencapai minimum requirement dan layak pakai. Oleh karena itu, dalam proses pengembangan peran testing sangat penting dan cukup krusial. Disamping engineer mengembangkan aplikasi, peran tester sendiri memastikan segala sesuatu yang ada dalam aplikasi dari hal kecil sampai besar dan tak kasat mata (cases yang tidak terpikiran oleh engineer) dapat memenuhi expektasi dari requirement diawal. Sehingga hal-hal yang tidak diinginkan tidak terjadi ketika aplikasi sudah masuk pasar (production). Dengan kata lain peran tester yakni mengusulkan, mengawasi, memonitoring, dan menguji software dari mulai tahap planning hingga release.

• Apa metode testing yang umum digunakan ?

Secara umum teknik testing untuk scope seorang tester yang sering diterapkan untuk menguji sebuah aplikasi ada 3 yakni black box, grey box, dan white box (conditional).

1. Black box

Black box testing adalah pengujian yang dilakukan hanya berdasarkan eksekusi melalui data uji dan memeriksa fungsional dari aplikasi. Jadi dianalogikan seperti kita melihat suatu kotak hitam, kita hanya bisa liat penampilan luarnya saja. Biasanya skenario pengujian dalam black box untuk mengevaluasi User Interface, dan fungsionalitas aplikasi apakah input dan output sudah bekerja secara benar dan tepat.

2. Grey box

Grey box testing adalah sebuah metode pengujian hasil dari kombinasi dari black box dan white box testing. Grey box testing mengacu pada teknik pengujian sistem dengan pengetahuan yang terbatas dari internal sistem, hanya saja secara tidak langsung tester tidak masuk ke dalam source code utama dari aplikasi. Pengujian grey box biasa dilakukan terhadap hal yang berhubungan dengan security, query database, pengujian compability aplikasi dalam berbagai OS, serta API (Application Programming Interface). Metode ini masih sering dapat diambil peran oleh tester. Karena case yang dilakukan dalam pengujian grey box, outputnya berdampak pada funcionality aplikasi yang berjalan.

3. White box

White box testing adalah pengujian yang mengacu pada struktur internal aplikasi. Pengujian ini biasanya untuk menguji input output dari masing-masing modul komponen atau fungsi terkecil dari aplikasi. Tujuan metode ini untuk memastikan secara programatikal bagaimana implementasi dari kode aplikasi secara satu persatu atau keseluruhan telah PASSED. Test coverage untuk pengujian ini biasanya dilakukan oleh engineer, karena secara utuh engineer yang lebih mengetahui bagaimana strukur dan desain kode dari program yang dibuat salah satunya diterapkan dalam unit testing, integration testing, dan system testing.

Dari ketiga metode diatas menjadi acuan dasar untuk menerapkan per-testing-an agar tester dapat lebih mudah dan memiliki petunjuk yang cukup untuk melakukan pengujian. Pada penerapannya, metode tersebut tidak menjadi aturan baku dan tidak semua metode atau mungkin hanya satu sampai dua metode yang diterapkan. Semua balik lagi pada kebutuhan dan urgensi kenapa seorang tester mesti melakukan metode-metode tersebut. Diluar itu ada hal yang lebih menarik yang mesti diketahui oleh seorang tester yakni memahami dan mendalami bahwa testing itu adalah layaknya sebuah seni.

Apa hubungan seni terhadap testing ?

Ketika metode / tools testing udah kita kuasain apakah cukup untuk menjadi tester yang qualified dan dapat diandalkan tim?. Berikut ada beberapa hal untuk menjadi bahan refleksi sejenak :

• Bayangin, ketika kita udah jago ngetes fitur A dan nemuin bug. Tapi bug yang kita report ke engineer sulit dimengerti dan direproduce ulang.
• Bayangin, saat sprint planning mungkin secara requirement dari product udah menjabarkan detail, hingga happy path udah runut dijelasin seperti apa. Tapi ternyata di luar dugaan banyak case yang seharusnya di validasi dan harus segera dapat feedback. Sebagai contoh, kalo misalnya data transaksi user yang telah didelete, apakah data transaksi tetep muncul ?
• Bayangin ketika udah mulai sprint, dan engineer mulai men-develop apakah kita cuma bisa diem aja nunggu tiket geser ke QA / in testing ?
• Bayangin ketika ada satu fitur yang sudah didevelop dan fitur tersebut berkaitan dengan fitur yang telah masuk production, apakah ada pengaruhnya?
• Bayangin ketika ada fitur yang sudah direlease ke production apakah kita lepas gitu aja atau ga ada pengecekan sama sekali?
• Bayangin ketika developer ngerjain tiket mood mood-an dan males geser tiket, apakah harus mengira tiket-tiket itu belum dikerjain?
• Bayangin apakah kita selalu berpikir ambil “jalan pintas” aja yang penting fitur bisa jalan dulu, tapi ga merhatiin dari sisi experince user pengaruhnya gimana?
• Bayangin ketika sudah ada tiket yang ngantri untuk dites, kita masih bingung mau mana dulu yang dites?
• Bayangin ketika ada bug diproduction, bagaimana kita mengkomunikasikannya dan segera menyelesaikan itu bareng engineer ?
• Bayangin bagaimana kalo ada bug yang terjadi di user, tetapi di kita tidak ter-reproduce ?
• Dan, bayangin bagaimana jika terdapat perubahan fitur secara mendadak dari PO ditengah-tengah development/sprint ?

Pertanyaan-pertanyaan diatas memiliki jawaban yang berbeda-beda. Tentu bergantung dari cara, budaya, metode, dan tools testing yang diterapkan oleh QA di masing-masing perusahaan. Namun, lagi-lagi kecenderungan awal orang adalah menjadi “follower” atau bahasa kesehariannya asal ikut aja dah atau asal testing, yang penting fitur udah dites dan bisa deploy hari ini atau bahkan selalu terpaku pada ketetapan baku pada proses testing yang sudah ada. Apabila hal tersebut dijadikan pakem atau satu-satunya acuan untuk melakukan testing dapat memberikan dampak yang kurang fleksibel. Akibatnya timbul kesulitan untuk beradaptasi terhadapa cepatnya arus perubahan requirement dari fitur yang tiba-tiba datang begitu saja. Jika sudah stuck dengan metode selama proses testing atau tools yang digunakan belum bisa membantu dalam proses identifikasi bug pada aplikasi, apa yang mesti dilakukan ?. Nah, disini pentingnya cara berpikir dan kerja seorang tester seperti seniman.

“Seniman handal bukan karena kuasnya bagus”

Tester yang handal bukan karena tools nya keren, melainkan kepiawaian dalam memanfaatkan konsep berpikir seorang tester, metode dan mengelola tools yang digunakan untuk ngetes. Layaknya seorang seniman, banyak hal tidak dapat dibatasi atas jiwa dan imajinasi kita yang tertuang dalam banyak cases pada satu atau banyak fitur. Tidak hanya sekedar mengandalkan base teori secara logic dan tekstual yang sudah ada, namun harus ada best practice-nya juga yang harus kita terapkan. Disamping sisi logika, dibutuhkan juga pertimbangan sisi kreativitas yakni untuk eksplorasi cases yang mungkin terjadi pada fitur yang akan didevelop, melakukan seni komunikasi (negotiable) dalam menyampaikan ide dan opini ke product manager/owner, seni dalam menulis dan menyampaikan report bug ke tim engineer sampai solved, hingga melakukan identifikasi dan analisis terhadap bug yang terjadi pada fase development atau production.

So semua orang bisa melukis, namun semua orang belum tentu betul-betul bisa jadi pelukis. Semua orang bisa melakukan testing, tapi belum tentu semua orang tahu best practices-nya cara ngetes fitur secara lihay dan handal tuh seperti apa. Ketika hal itu bisa terealisasi, diharapkan kehadiran tester mampu menjadi katalisator dalam melakukan pencapaian quality and deliver better pada aplikasi yang dibuat.